CrashPlan

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

インストール

基本的な使い方

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 トンネルを作成することです。

サーバー上で CrashPlan デーモンを起動します。
SSH トンネルを作成する。クライアントで ssh -N -L 4243:localhost:4243 headless.example.com
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

参照