で大容量HDDをバックアップする予定でrsync
、数日かかると予想しています。rsync
作業中に元のHDDを使用(ファイルを追加)しても安全ですか?または、rsync
終了するまでHDDをそのままにしておく方が良いでしょうか?
で大容量HDDをバックアップする予定でrsync
、数日かかると予想しています。rsync
作業中に元のHDDを使用(ファイルを追加)しても安全ですか?または、rsync
終了するまでHDDをそのままにしておく方が良いでしょうか?
回答:
他の人がすでに指摘しているように、rsyncの実行中は、ソースディスクから読み取るか、ターゲットディレクトリの外でターゲットディスクを使用しても安全です。また、特にターゲットディレクトリがrsyncの実行によって排他的に読み込まれている場合、ターゲットディレクトリ内で読み取ることは安全です。
一般に安全でないのは、rsyncの実行中にソースディレクトリ内に書き込むことです。「書き込み」とは、ソースディレクトリまたはそのサブディレクトリの内容を変更するものであり、ファイルの更新、削除、作成などが含まれます。
これを行っても実際には何も壊れませんが、変更はターゲットの場所にコピーするためにrsyncによって実際に反映される場合とされない場合があります。それは、変更の種類、rsyncがその特定のディレクトリをまだスキャンしているかどうか、rsyncが問題のファイルまたはディレクトリをまだコピーしているかどうかによって異なります。
ただし、それを回避する簡単な方法があります。終了したら、同じパラメーターでrsyncを再度実行します。(ファンキーな削除パラメーターがある場合を除き、そうする場合は、もう少し注意してください。)そうすると、ソースが再スキャンされ、元の実行中に検出されなかった差異が転送されます。
2回目の実行では、前回のrsyncの実行中に発生した差異のみを転送する必要があり、そのため、はるかに高速に完了します。したがって、最初の実行中は通常どおりコンピューターを自由に使用できますが、2回目の実行中はソースに変更を加えないようにしてください。可能であれば、2回目のrsyncの実行を開始する前に、ソースファイルシステムを読み取り専用で再マウントすることを強くお勧めします。(のような何かがmount -o ro,remount /media/source
すべきです。)
@reboot root find / -print &>/dev/null
が、システムcrontabによく似たエントリがあり、キャッシュにデータを入力します。(実際のエントリは、特定のシステムのいくつかの特別なケースを考慮するとより複雑です。)起動後のRAMとウォールクロック時間を使用して、ディレクトリツリースキャンをかなりIMEで改善します。
updatedb
locateのデータベースを構築する)またはslocate -u
(slocateがある場合は同じ)を実行する必要がありますか?この方法では、階層をキャッシュしますが、locateまたはslocateのデータベースも構築し、これらのコマンドを使用して多くのファイルをすばやく見つけることができますか?
これは、使用するバックアップシステムによって異なりますが、一般に、バックアップ中にデバイスの内容を変更することはお勧めできません。ただし、その内容は読むことができます。プロセスが遅くなる場合でも、これは安全な操作です。
あなたの場合、rsync
ファイルリストを作成してからバックアップを開始します。したがって、バックアップの開始後にソースHDDに追加したファイルはコピーされません。
私がしていることは、バックアップ中にデバイスをまったく使用しないことです。これは、高速で一貫したバックアップを取得するためのより安全な方法です。
rsync
中に変更したファイルのみがコピーされるため、通常は実行してから2回目の実行を数秒で完了します。すべてがキャッシュ内にあるため、その期間中の変更は控える方が簡単です。
rsync
動作中にソース領域からデータを読み取ることは安全ですが、何かを更新すると、rsync
作成/更新するコピーに一貫性がなくなる可能性があります。
rsyncがすでにスキャンしたファイルを更新する場合、将来の実行まで更新は表示されません。まだスキャンしていないファイルを更新する場合、変更は宛先で尊重されます。スキャンされたファイルとスキャンされていないファイルの両方を更新すると、宛先に古いバージョンと新しいバージョンが混在することになります。
スキャン済みのディレクトリにファイルを追加すると、今回はコピー先からファイルが失われます。スキャン済みのディレクトリからファイルを削除すると、今回はコピー先に残されます。起動方法に応じてrsync
、ツリー全体が最初にスキャンされるか、同期プロセスが発生するにつれてツリーが増分的にスキャンされます。
状況rsync
によっては、矛盾を確認して警告します。既にスキャンされているが、そのコンテンツがスキャンされていないディレクトリからファイルまたはサブディレクトリを削除すると、オブジェクトが見つからないというエラーメッセージが表示されます。同様の状況で、サイズやタイムスタンプが変更された場合、スキャン中にファイルが変更されることを警告することもあります。
一部のバックアップでは、この不整合は大きな問題ではないかもしれませんが、ほとんどの場合、アクティブに変化するソースを同期しようとしないことをお勧めします。
LVMを使用してストレージシステムを分割する場合、一時的なスナップショットを使用してポイントインタイムバックアップを作成できます。これには、スナップショットが必要な期間に発生するすべての変更を保持するのに十分な大きさのスナップショットボリュームを作成するために、ボリュームグループに十分なスペースが必要です。詳細については、LVMのドキュメント(または多くのオンライン例の1つ:「LVMスナップショットバックアップ」などを検索してください)を確認してください。
LVMがなくても、一部のファイルシステムはスナップショット自体をサポートしているため、そのオプションも検討してください。
長いダウンタイムなしで大きなアクティブボリュームをバックアップし、スナップショットを使用できない場合は、「ライブ」スキャンを最後まで実行し、ボリュームへのアクセスを停止して、はるかに短い時間で別のrsyncプロセスを実行するだけで十分な場合があります(変更はほとんどなく、ディレクトリツリーをスキャンしてから、更新されたいくつかのファイルをスキャンします)。これにより、変更を回避する必要がある期間を大幅に短縮できます。
現在の答えはすべて、一貫性の観点からデータの安全性について語り、完全なハードウェアを想定しています。
考慮すべきもう1つのことは、ハードウェアの安全性自体です。障害が発生しそうなバックアップされていないハードドライブがあり(まだわからない場合もあります)、最初の包括的なバックアップを作成している場合は、使用しないでください。データが重要な場合はマウントしないでください。dd
ディスクをブロックデバイスとして複製するなどのツールを使用できます。ディスクヘッドがバックアップを作成しようとしている間にディスクヘッドがシークし、場合によっては書き込みをしたくないこと。Plus dd
はビットを順番にコピーするだけなので、最初のバックアップの方が高速である必要があります(ドライブがほとんど満杯でない場合、rsyncが最初のケースでも勝つと思います)。
後続の増分バックアップでは、rsyncが最適な選択肢であり、他の回答に100%同意します。
dd
、最良の選択ではありません。ddrescue
代わりに使用してください。部分的な障害をより良く処理します。しかし、それは元の質問では考慮されていませんでした。