rsyncの実行中にHDDを使用しても安全ですか?


27

で大容量HDDをバックアップする予定でrsync、数日かかると予想しています。rsync作業中に元のHDDを使用(ファイルを追加)しても安全ですか?または、rsync終了するまでHDDをそのままにしておく方が良いでしょうか?


1
「使用」は、ブラウザを開いて何もしないのと同じくらい簡単な場合があることに注意してください。ブラウザは、データディレクトリに多くのランダムなものを書き込む傾向があります。最悪の場合、取得するのは一貫性のないバックアップです。つまり、復元時にタブを復元できなかったり、ブックマークがなくなったり(データベースが破損しているため)、その程度の大きさであったりします。
ジョナスシェーファー

バックアップするデータが大量にある場合は、バックアップを小さな断片(サブツリー)に分割することを検討してください。次に、現在実行中の部分のみを可能な限り静的に維持する必要があります。スクリプトの進行状況を(ログなどを使用して)追跡することで、どの部分であるかを確認できます。1つの大きなバックアップではないため、いくつかの部分は他の部分と少し同期が取れていない可能性がありますが、ライブシステムで1つの大きなバックアップを実行している場合は、とにかく起こります。
ジョー

回答:


34

他の人がすでに指摘しているように、rsyncの実行中は、ソースディスクから読み取るか、ターゲットディレクトリの外でターゲットディスクを使用しても安全です。また、特にターゲットディレクトリがrsyncの実行によって排他的に読み込まれている場合、ターゲットディレクトリ内で読み取ることは安全です。

一般に安全でないのは、rsyncの実行中にソースディレクトリ内書き込むことです。「書き込み」とは、ソースディレクトリまたはそのサブディレクトリの内容を変更するものであり、ファイルの更新、削除、作成などが含まれます。

これを行っても実際には何も壊れませんが、変更はターゲットの場所にコピーするためにrsyncによって実際に反映される場合とされない場合があります。それは、変更の種類、rsyncがその特定のディレクトリをまだスキャンしているかどうか、rsyncが問題のファイルまたはディレクトリをまだコピーしているかどうかによって異なります。

ただし、それを回避する簡単な方法があります。終了したら、同じパラメーターでrsyncを再度実行します。(ファンキーな削除パラメーターがある場合を除き、そうする場合は、もう少し注意してください。)そうすると、ソースが再スキャンされ、元の実行中に検出されなかった差異が転送されます。

2回目の実行では、前回のrsyncの実行中に発生した差異のみを転送する必要があり、そのため、はるかに高速に完了します。したがって、最初の実行中は通常どおりコンピューターを自由に使用できますが、2回目の実行中はソースに変更を加えないようにしてください。可能であれば、2回目のrsyncの実行を開始する前に、ソースファイルシステムを読み取り専用で再マウントすることを強くお勧めします。(のような何かがmount -o ro,remount /media/sourceすべきです。)


7
2回目の実行後に3回目の実行を行うこともできます。さらに時間がかかる場合があります...
;

5
@gerlosパターンが出現しているようです。各使用セッションの終わりにrsyncコマンドを実行し続けることができ、数日以内にすぐに実行できるように思えます。
モンティハーダー

5
@gerlos 2回目のrsyncを実行する前に読み取り専用で再マウントする場合、これは不要であり、ソースファイルシステムに書き込むことができない時間を最小限に抑えながら、バックアップの一貫性が保証されます。
CVn

1
@gerlos余談です@reboot root find / -print &>/dev/nullが、システムcrontabによく似たエントリがあり、キャッシュにデータを入力します。(実際のエントリは、特定のシステムのいくつかの特別なケースを考慮するとより複雑です。)起動後のRAMとウォールクロック時間を使用して、ディレクトリツリースキャンをかなりIMEで改善します。
CVn

1
@MichaelKjörling:階層をキャッシュする興味深いアイデア。しかし、代わりに(updatedblocateのデータベースを構築する)またはslocate -u(slocateがある場合は同じ)を実行する必要がありますか?この方法では、階層をキャッシュしますが、locateまたはslocateのデータベースも構築し、これらのコマンドを使用して多くのファイルをすばやく見つけることができますか?
オリビエデュラック

22

これは、使用するバックアップシステムによって異なりますが、一般に、バックアップ中にデバイスの内容を変更することはお勧めできません。ただし、その内容は読むことができます。プロセスが遅くなる場合でも、これは安全な操作です。

あなたの場合、rsyncファイルリストを作成してからバックアップを開始します。したがって、バックアップの開始後にソースHDDに追加したファイルはコピーされません。

私がしていることは、バックアップ中にデバイスをまったく使用しないことです。これは、高速で一貫したバックアップを取得するためのより安全な方法です。


14
実行rsync中に変更したファイルのみがコピーされるため、通常は実行してから2回目の実行を数秒で完了します。すべてがキャッシュ内にあるため、その期間中の変更は控える方が簡単です。
マーティンUeding

15

rsync動作中にソース領域からデータを読み取ることは安全ですが、何かを更新すると、rsync作成/更新するコピーに一貫性がなくなる可能性があります。

  1. rsyncがすでにスキャンしたファイルを更新する場合、将来の実行まで更新は表示されません。まだスキャンしていないファイルを更新する場合、変更は宛先で尊重されます。スキャンされたファイルとスキャンされていないファイルの両方を更新すると、宛先に古いバージョンと新しいバージョンが混在することになります。

  2. スキャン済みのディレクトリにファイルを追加すると、今回はコピー先からファイルが失われます。スキャン済みのディレクトリからファイルを削除すると、今回はコピー先に残されます。起動方法に応じてrsync、ツリー全体が最初にスキャンされるか、同期プロセスが発生するにつれてツリーが増分的にスキャンされます。

  3. 状況rsyncによっては、矛盾を確認して警告します。既にスキャンされているが、そのコンテンツがスキャンされていないディレクトリからファイルまたはサブディレクトリを削除すると、オブジェクトが見つからないというエラーメッセージが表示されます。同様の状況で、サイズやタイムスタンプが変更された場合、スキャン中にファイルが変更されることを警告することもあります。

一部のバックアップでは、この不整合は大きな問題ではないかもしれませんが、ほとんどの場合、アクティブに変化するソースを同期しようとしないことをお勧めします。

LVMを使用してストレージシステムを分割する場合、一時的なスナップショットを使用してポイントインタイムバックアップを作成できます。これには、スナップショットが必要な期間に発生するすべての変更を保持するのに十分な大きさのスナップショットボリュームを作成するために、ボリュームグループに十分なスペースが必要です。詳細については、LVMのドキュメント(または多くのオンライン例の1つ:「LVMスナップショットバックアップ」などを検索してください)を確認してください。

LVMがなくても、一部のファイルシステムはスナップショット自体をサポートしているため、そのオプションも検討してください。

長いダウンタイムなしで大きなアクティブボリュームをバックアップし、スナップショットを使用できない場合は、「ライブ」スキャンを最後まで実行し、ボリュームへのアクセスを停止して、はるかに短い時間で別のrsyncプロセスを実行するだけで十分な場合があります(変更はほとんどなく、ディレクトリツリーをスキャンしてから、更新されたいくつかのファイルをスキャンします)。これにより、変更を回避する必要がある期間を大幅に短縮できます。


ファイルが変更された場合に何が起こるかについて詳しく説明するので、私はあなたの答えが一番好きです。代替手段を提供するだけでなく、それが原因で生じる可能性のある不整合(更新の欠落、ファイルの欠落に関する警告など)にも対処します。私の状況では、rsyncを使用して長いバックアップをシードし、数日後にそれを更新することは大したことではなく、それはOPの状況のようにも聞こえます。初めてエンタープライズレベルのバックアップを必要としているようには見えませんが、その間にコンピューターを使用したいだけです。更新されたファイルをキャッチするために、もう一度rsyncを実行するだけです。
-ibennetch

11
  • ソースHDDはrsync中に何でも読むことができます。

  • ソースHDDは、rsyncコンテンツに関連しないコンテンツを書き込むことができます。

  • デスティネーションHDDは、rsync中に何でも読み取ることができます。

  • 同期されたコンテンツ用に十分なスペースを確保する条件で、rsyncの間に宛先HDDは何でも書き込むことができます。

もちろん、いずれの場合でも、パフォーマンスが低下します。


0

現在の答えはすべて、一貫性の観点からデータの安全性について語り、完全なハードウェアを想定しています。

考慮すべきもう1つのことは、ハードウェアの安全性自体です。障害が発生しそうなバックアップされていないハードドライブがあり(まだわからない場合もあります)、最初の包括的なバックアップを作成している場合は、使用しないでください。データが重要な場合はマウントしないでください。ddディスクをブロックデバイスとして複製するなどのツールを使用できます。ディスクヘッドがバックアップを作成しようとしている間にディスクヘッドがシークし、場合によっては書き込みをしたくないこと。Plus ddはビットを順番にコピーするだけなので、最初のバックアップの方が高速である必要があります(ドライブがほとんど満杯でない場合、rsyncが最初のケースでも勝つと思います)。

後続の増分バックアップでは、rsyncが最適な選択肢であり、他の回答に100%同意します。


1
メディアが限界的であるか、潜在的に限界的である場合でもdd、最良の選択ではありません。ddrescue代わりに使用してください。部分的な障害をより良く処理します。しかし、それは元の質問では考慮されていませんでした。
からCVn

@MichaelKjörlingそれは良い点です。
ザック
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.