私は、OSXクライアントマシンを多数使用しており、タイムマシンnetatalk/afpd によってエクスポートされた、Ubuntu Linux ファイル サーバー上の AFP 共有に。これらのクライアントは、毎日任意の時間にバックアップします。サーバーには、TimeMachine 以外の重要な AFP 共有も存在します。
サーバー上では、TimeMachineバックアップは次のように表されます。スパースバンドル- 多くの「バンド」を含むデータ ストレージ形式 - 標準の EXT4 ファイルシステムに保存されます。このスパースバンドル内には、TimeMachine が使用する HFS+ ファイルシステムのディスク イメージが埋め込まれていますが、サーバー側からは、バンド ファイルといくつかのトップレベルのメタデータのコレクションにすぎません。
スナップショットサーバー上で 4 時間ごとに実行され、スパースバンドル バンド ファイルとメタデータをリムーバブル メディア (オフサイト ストレージ用) にバックアップします。したがって、rsnapshot はこれらのスパースバンドル バンドを 1 日の任意の時間にバックアップします。rsnapshot は rsync を使用してコピーを実行します。
問題は、クライアント マシンにスパースバンドルがマウントされている状態で rsnapshot を実行すると、バックアップ プロセス中にバンドが変わる可能性があるため、rsnapshot がスパースバンドルの不整合な状態をキャプチャする可能性があることです。明らかに、これは復元可能なバックアップを保証することには役立ちません。
この問題を回避する方法を考えようとしています。rsnapshot がバックアップを試みているときに sparsebundle がマウントされていないことが重要であるようです。サーバー側からこれを行うには、おそらく sparsebundle が OSX クライアントによってアンマウントされるのを待ってから、aftp デーモンを停止するしかないと思います。この方法の欠点は、他の非 TimeMachine AFP エクスポートもオフラインになることで、これはユーザーにとって受け入れがたいことです。私の知る限り、afpd はエクスポートを (簡単に) 追加または削除する方法を提供していません。ただし、1 つのオプションとして、rsnapshot バックアップ中に TM エクスポートを無効にするために afpd の構成ファイルを自動的に書き換える方法がありますが、それでも AFP 共有は短時間停止します。
もっと良い方法はあるでしょうか?
答え1
Mac コンピューターのグループには Time Machine は使用しないでください。スパース バンドルやバックアップの破損に関する問題が多すぎます。
同様の状況に直面したとき、Time Machine アプローチは本番環境に適していないことがわかり、CrashPlan を選択しました。
答え2
考え。
実際のバックアップには Mac デバイス自体でスナップショットを実行し、Time Machine バックアップは補足となります。
はい、復元には Time Machine イメージを使用する方がはるかに優れていますが、rsnapshot を使用してファイルを用意しておくのも素晴らしいアイデアです。
私は、rsync またはスナップショット イメージを保存するために、Jungle Disk を使用して Amazon S3 にマウントされたドライブを使用しています。