「CrashPlan」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
細 (カテゴリ変更)
 
(2人の利用者による、間の7版が非表示)
3行目: 3行目:
 
CrashPlan はリモートサーバーや他のコンピュータ、ハードドライブなどにデータをバックアップするバックアッププログラムです。クラウドサーバーにバックアップするには月額課金が必要です。
  
CrashPlan はリモートサーバーや他のコンピュータ、ハードドライブなどにデータをバックアップするバックアッププログラムです。クラウドサーバーにバックアップするには月額課金が必要です。
   
−
==インストール==
 +
== インストール ==
   
  +
{{AUR|crashplan-pro}} を [[インストール]] して下さい。
−
[[AUR]] から {{AUR|crashplan}}{{Broken package link|パッケージが存在しません}} をインストールしてください。有料のエンタープライズパッケージとして {{AUR|crashplan-pro}} や {{AUR|crashplan-pro-e}} もあります。
  
   
−
==基本的な使い方==
 +
== 基本的な使い方 ==
   
−
CrashPlan のグラフィカルユーザーインターフェイスを使う前に、サービスを起動してください:
 +
CrashPlan のグラフィカルユーザーインターフェイスにアクセスする前に、{{ic|crashplan-pro.service}} ユニットを [[起動]] する必要があります。
   
  +
CrashPlan は、グラフィカルユーザーインターフェイスを通じて完全に設定できます。グラフィカルインターフェイスを開始するには:
−
# systemctl start crashplan.service
  
−  
−
CrashPlan の設定は全てグラフィカルユーザーインターフェイスで行うことができます。グラフィカルインターフェイスを起動するには:
  
   
 
$ CrashPlanDesktop
  
$ CrashPlanDesktop
   
−
システムの起動時に CrashPlan を自動的に実行するには:
 +
システム起動時に CrashPlan が自動的に開始されるようにするには、systemd ユニットを [[有効化]] します。
   
  +
== ヘッドレスサーバーで Crashplan を実行 ==
−
# systemctl enable crashplan.service
  
   
−
==ヘッドレスサーバーで Crashplan を実行==
 +
ヘッドレスサーバーでの CrashPlan の実行は正式にサポートされていません。ただし、実行することは可能です。
   
  +
CrashPlan デーモンの設定ファイル ({{ic|/opt/crashplan/conf}}) は、分かりづらい XML 形式であり、CrashPlan クライアントによって編集されることを目的としています。
−
ヘッドレスサーバーでの CrashPlan の実行は公式ではサポートされていませんが、可能ではあります。
  
   
  +
CrashPlan 5 では新しいクライアントが導入されましたが、残念ながらローカルクライアントを使用したリモートサーバーの設定のサポートが廃止されたため、X11 転送を使用する必要があります。
−
CrashPlan デーモンの設定ファイル ({{ic|/opt/crashplan/conf}}) は謎の XML 形式で記述されており、CrashPlan クライアントによってプログラムで編集することを想定しています。CrashPlan のクライアントとデーモンはデフォルトでポート 4243 で通信します。従って、ヘッドレスサーバーで CrashPlan デーモンを設定する簡単な方法は SSH トンネルを作成することです:
  
   
  +
=== SSH 経由での X11 転送 ===
−
# CrashPlan デーモンを起動。サーバー側で: {{ic|systemctl start crashplan.service}}。
  
−
# SSH トンネルを作成。クライアント側で: {{ic|ssh -N -L 4243:localhost:4243 headless.example.com}}。
  
−
# CrashPlan クライアントを起動 (実行可能ファイルの名前は {{ic|CrashPlanDesktop}})。
  
   
  +
ヘッドレスサーバーの {{ic|/etc/ssh/sshd_config}} で {{ic|X11Forwarding}} が {{ic|yes}} に設定されていることを確認し、X11 を実行している別のマシンから、{{ic|-Y}} で SSH 接続し、リモートシェルから {{ic|CrashPlanDesktop}} を実行します。ヘッドレスマシンのウィンドウがローカルの X11 サーバーに表示されます。問題があれば {{ic|/opt/crashplan/log/ui_error.log}} を確認してください。
−
詳細は以下のウェブサイトに載っています:
  
   
  +
=== ローカルクライアント ===
−
* CrashPlan のサポートサイトには SSH トンネルを使ってクライアント (CrashPlan Desktop) からデーモン (CrashPlan Engine) への通信をトンネリングする、やや複雑な方法の [http://support.code42.com/CrashPlan/Latest/Configuring/Configuring_A_Headless_Client 説明] があります。
  
−
* [http://www.liquidstate.net/how-to-manage-your-crashplan-server-remotely/ Bryan Ross による記事] では CrashPlan Engine に直接 CrashPlan Desktop を接続する方法が書かれています。この方法は SSH トンネルを使わないため安全性に欠けるので注意してください。
  
   
  +
CrashPlan v4.x 以前では、クライアントとデーモンはデフォルトでポート 4243 で通信します。したがって、ヘッドレスサーバー上で CrashPlan デーモンを設定する簡単な方法は、SSH トンネルを作成することです。
−
==トラブルシューティング==
  
   
  +
# サーバー上で CrashPlan デーモンを [[起動]] します。
−
===接続の待機===
  
  +
# SSH トンネルを作成する。クライアントで {{ic|ssh -N -L 4243:localhost:4243 headless.example.com}}
  +
# CrashPlan クライアントを起動する。(ここでの実行ファイルは {{ic|CrashPlanDesktop}} という名前です)
   
  +
ローカルサーバーとリモートサーバーの認証トークンは、({{ic|/var/lib/crashplan/.ui_info}} にあります) これらは、一致する必要があることに注意してください。さらに多くのアイデアが次の Web サイトで見つかります。
−
システムによってはインターネット接続が確立するまで CrashPlan が待機しないことがあります。[[NetworkManager]] を使用している場合、{{AUR|networkmanager-dispatcher-crashplan-systemd}}{{Broken package link|{{aur-mirror|networkmanager-dispatcher-crashplan-systemd}}}} をインストールすることで接続が確立したときに CrashPlan のサービスを自動的に再起動させることができます。
  
  +
  +
* CrashPlan のサポートサイト [https://web.archive.org/web/20210224184059/https://support.code42.com/CrashPlan/4/Configuring/Use_CrashPlan_on_a_headless_computer 詳細] では、クライアント (CrashPlan Desktop) からデーモン (CrashPlan Engine) に SSH トンネルを通してトラフィックをトンネリングする少し複雑な方法が紹介されています。
  +
* [https://www.liquidstate.net/how-to-manage-your-crashplan-server-remotely/ Bryan Ross による投稿] では、CrashPlan デスクトップを CrashPlan エンジンに直接接続する方法について詳しく説明しています。この方法は、SSH トンネルを介してトラフィックをトンネリングするよりも安全性が劣る可能性があることに注意してください。
  +
  +
==トラブルシューティング==
   
 
===バックアップの待機===
  
===バックアップの待機===
   
−
«Waiting for Backup» でバックアップが止まってしまう場合、おそらく一時ディレクトリに CrashPlan がアクセスできないか {{ic|noexec}} でマウントされています。CrashPlan ではデフォルトの Java の一時ディレクトリ (通常は {{ic|/tmp}}) を使います。{{ic|noexec}} マウントオプションを削除するか (推奨されません) または CrashPlan が使用する一時ディレクトリを変更してください。
 +
バックアップを手動で実行しても «Waiting for Backup» で止まっている場合、CrashPlan が tempdir にアクセスできないか、tempdir が {{ic|noexec}} としてマウントされている可能性があります。デフォルトの Java の tmp ディレクトリは通常{{ic|/tmp}} です。マウントオプション {{ic|noexec}} を削除するか (推奨はしません)、CrashPlan が使用している tmpdir を変更してください。
   
−
CrashPlan が使用する一時ディレクトリを変更するには、{{ic|/opt/crashplan/bin/run.conf}} を開いて {{ic|-Djava.io.tmpdir=/new-tempdir}} を {{ic|SRV_JAVA_OPTS}} に追加します、例:
 +
CrashPlan が使用する tmpdir を変更するには、{{ic|/opt/crashplan/bin/run.conf}} を開き、{{ic|1=-Djava.io.tmpdir=/new-tempdir}} を {{ic|SRV_JAVA_OPTS}} に挿入します。例えば:
   
−
SRV_JAVA_OPTS="-Djava.io.tmpdir=/var/tmp/crashplan -Dfile.encoding=UTF-8 …
 +
SRV_JAVA_OPTS="-Djava.io.tmpdir=/var/tmp/crashplan -Dfile.encoding=UTF-8 ...
   
−
新しい一時ディレクトリを作成して CrashPlan のユーザーがアクセスできることを確認してください。
 +
必ず新しい tmpdir を作成し、CrashPlan のユーザーがそれにアクセスできることを確認してください。
 
# mkdir /var/tmp/crashplan
  
# mkdir /var/tmp/crashplan
   
−
CrashPlan を再起動します:
 +
CrashPlan を [[再起動]] します。
  +
−
# systemctl restart crashplan
  
  +
=== 復元の準備が停止している ===
  +
  +
リストアが «Preparing» で停止する場合、{{ic|/tmp}} のパーミッション制限によりリストアツールとバックアップエンジン間の通信が失敗している可能性があります。これは sysctl 変数 {{ic|fs.protected_fifos}} が、エンジン({{ic|root}} として実行中) が {{ic|/tmp}} に含まれるデスクトップユーザーが所有する名前付きパイプへの接続を制限していることが原因である可能性があります。([[tmpfs# root で tmpfs のシンボリックリンクを開けない]] と同様)
  +
  +
保護を無効にして復元を許可することができます。
  +
  +
# sysctl fs.protected_fifos=0
  +
  +
バージョン 241 以降の systemd では、このオプションがデフォルトで 1 に設定されます。正しく変更する方法については [https://github.com/systemd/systemd/blob/2732587540035227fe59e4b64b60127352611b35/NEWS#L32 systemd ドキュメント] を参照し、詳細については [[Sysctl]] を参照してください。
   
 
===Desktop GUI が起動時にクラッシュする===
  
===Desktop GUI が起動時にクラッシュする===
66行目: 77行目:
 
===リアルタイム保護===
  
===リアルタイム保護===
 
バックアップのリアルタイム保護を使用して、大量のファイルをバックアップする場合、デフォルトのシステム設定ではリアルタイムですべてのファイルを処理することができません。syslog のジャーナルに "inotify_add_watch: No space left on device" というようなログが発生するのでわかります。[http://support.code42.com/CrashPlan/Latest/Troubleshooting/Real-Time_Backup_For_Network-Attached_Drives こちら] の指示に従って inotify の max_user_watches を大きな値に設定することで問題は解決します。
  
バックアップのリアルタイム保護を使用して、大量のファイルをバックアップする場合、デフォルトのシステム設定ではリアルタイムですべてのファイルを処理することができません。syslog のジャーナルに "inotify_add_watch: No space left on device" というようなログが発生するのでわかります。[http://support.code42.com/CrashPlan/Latest/Troubleshooting/Real-Time_Backup_For_Network-Attached_Drives こちら] の指示に従って inotify の max_user_watches を大きな値に設定することで問題は解決します。
  +
  +
=== JRE バージョンアップデート ===
  +
  +
アップグレード中に、CrashPlan が自己インストールされた JRE バージョンのアップグレードを試行し、CrashPlan から JRE をダウンロードしてもアップグレードが成功しない場合 (logs/upgrade<unique_number>.log をチェックして下さい、''最後'' のメッセージは curl/wget for the JRE tgz) です、JRE を (ugprade ログから) 手動でダウンロードし、CrashPlan インストール内の jre フォルダーをアップグレードバージョンに置き換えることができます。これにより、CrashPlan が JRE のアップグレード中に停止する問題を回避できるようになります。
  +
  +
cd <crashplan/install/dir>
  +
./bin/CrashPlanEngine stop
  +
rm -rf jre
  +
curl <jre url from crashplan log>
  +
tar xzvf <jre.tgz>
  +
./bin/CrashPlanEngine start
   
 
==参照==
  
==参照==

2023年11月10日 (金) 13:08時点における最新版

CrashPlan はリモートサーバーや他のコンピュータ、ハードドライブなどにデータをバックアップするバックアッププログラムです。クラウドサーバーにバックアップするには月額課金が必要です。

インストール

crashplan-proAUR を インストール して下さい。

基本的な使い方

CrashPlan のグラフィカルユーザーインターフェイスにアクセスする前に、crashplan-pro.service ユニットを 起動 する必要があります。

CrashPlan は、グラフィカルユーザーインターフェイスを通じて完全に設定できます。グラフィカルインターフェイスを開始するには: 

$ CrashPlanDesktop

システム起動時に CrashPlan が自動的に開始されるようにするには、systemd ユニットを 有効化 します。

ヘッドレスサーバーで Crashplan を実行

ヘッドレスサーバーでの CrashPlan の実行は正式にサポートされていません。ただし、実行することは可能です。

CrashPlan デーモンの設定ファイル (/opt/crashplan/conf) は、分かりづらい XML 形式であり、CrashPlan クライアントによって編集されることを目的としています。

CrashPlan 5 では新しいクライアントが導入されましたが、残念ながらローカルクライアントを使用したリモートサーバーの設定のサポートが廃止されたため、X11 転送を使用する必要があります。

SSH 経由での X11 転送

ヘッドレスサーバーの /etc/ssh/sshd_config で X11Forwarding が yes に設定されていることを確認し、X11 を実行している別のマシンから、-Y で SSH 接続し、リモートシェルから CrashPlanDesktop を実行します。ヘッドレスマシンのウィンドウがローカルの X11 サーバーに表示されます。問題があれば /opt/crashplan/log/ui_error.log を確認してください。

ローカルクライアント

CrashPlan v4.x 以前では、クライアントとデーモンはデフォルトでポート 4243 で通信します。したがって、ヘッドレスサーバー上で CrashPlan デーモンを設定する簡単な方法は、SSH トンネルを作成することです。

  1. サーバー上で CrashPlan デーモンを 起動 します。
  2. SSH トンネルを作成する。クライアントで ssh -N -L 4243:localhost:4243 headless.example.com
  3. CrashPlan クライアントを起動する。(ここでの実行ファイルは CrashPlanDesktop という名前です)

ローカルサーバーとリモートサーバーの認証トークンは、(/var/lib/crashplan/.ui_info にあります) これらは、一致する必要があることに注意してください。さらに多くのアイデアが次の Web サイトで見つかります。

  • CrashPlan のサポートサイト 詳細 では、クライアント (CrashPlan Desktop) からデーモン (CrashPlan Engine) に SSH トンネルを通してトラフィックをトンネリングする少し複雑な方法が紹介されています。
  • Bryan Ross による投稿 では、CrashPlan デスクトップを CrashPlan エンジンに直接接続する方法について詳しく説明しています。この方法は、SSH トンネルを介してトラフィックをトンネリングするよりも安全性が劣る可能性があることに注意してください。

トラブルシューティング

バックアップの待機

バックアップを手動で実行しても «Waiting for Backup» で止まっている場合、CrashPlan が tempdir にアクセスできないか、tempdir が noexec としてマウントされている可能性があります。デフォルトの Java の tmp ディレクトリは通常/tmp です。マウントオプション noexec を削除するか (推奨はしません)、CrashPlan が使用している tmpdir を変更してください。

CrashPlan が使用する tmpdir を変更するには、/opt/crashplan/bin/run.conf を開き、-Djava.io.tmpdir=/new-tempdir を SRV_JAVA_OPTS に挿入します。例えば: 

SRV_JAVA_OPTS="-Djava.io.tmpdir=/var/tmp/crashplan -Dfile.encoding=UTF-8 ...

必ず新しい tmpdir を作成し、CrashPlan のユーザーがそれにアクセスできることを確認してください。 

# mkdir /var/tmp/crashplan

CrashPlan を 再起動 します。

復元の準備が停止している

リストアが «Preparing» で停止する場合、/tmp のパーミッション制限によりリストアツールとバックアップエンジン間の通信が失敗している可能性があります。これは sysctl 変数 fs.protected_fifos が、エンジン(root として実行中) が /tmp に含まれるデスクトップユーザーが所有する名前付きパイプへの接続を制限していることが原因である可能性があります。(tmpfs# root で tmpfs のシンボリックリンクを開けない と同様)

保護を無効にして復元を許可することができます。 

# sysctl fs.protected_fifos=0

バージョン 241 以降の systemd では、このオプションがデフォルトで 1 に設定されます。正しく変更する方法については systemd ドキュメント を参照し、詳細については Sysctl を参照してください。

Desktop GUI が起動時にクラッシュする

GNOME 3 がインストールされている場合、または libwebkit-gtk がインストールされている場合、起動時に GUI がクラッシュする問題が発生することがあります。こちら の手順に従うことで修正できます。

メモリ不足

大量のファイル (100,000 以上) をバックアップに設定する場合、デフォルトの最大ヒープサイズは小さすぎます。ヒープが一杯になると、サーバーは何もエラーを表示せずに再起動を行い、メモリーが限界になるまで再起動し続けます。サービスが再起動するたびに /opt/crashplan/bin に小さなログファイルが大量に作成されるのでわかります (いつまでも問題に気づかないと際限なく数は膨らみます)。ヒープサイズの上限を上げるには、/opt/crashplan/bin/run.conf の -Xmx オプションを適当な値に調整してください。

リアルタイム保護

バックアップのリアルタイム保護を使用して、大量のファイルをバックアップする場合、デフォルトのシステム設定ではリアルタイムですべてのファイルを処理することができません。syslog のジャーナルに "inotify_add_watch: No space left on device" というようなログが発生するのでわかります。こちら の指示に従って inotify の max_user_watches を大きな値に設定することで問題は解決します。

JRE バージョンアップデート

アップグレード中に、CrashPlan が自己インストールされた JRE バージョンのアップグレードを試行し、CrashPlan から JRE をダウンロードしてもアップグレードが成功しない場合 (logs/upgrade<unique_number>.log をチェックして下さい、最後 のメッセージは curl/wget for the JRE tgz) です、JRE を (ugprade ログから) 手動でダウンロードし、CrashPlan インストール内の jre フォルダーをアップグレードバージョンに置き換えることができます。これにより、CrashPlan が JRE のアップグレード中に停止する問題を回避できるようになります。 

 cd <crashplan/install/dir>
 ./bin/CrashPlanEngine stop
 rm -rf jre
 curl <jre url from crashplan log>
 tar xzvf <jre.tgz>
 ./bin/CrashPlanEngine start

参照

「https://wiki.archlinux.jp/index.php?title=CrashPlan&oldid=34778」から取得