スクリプト化されていない限り書き込み検証が行われないことを考えると (または、スクリプト化が必要ですか?)、いくつかのフォルダーを別のサーバーにダンプすることは適切なオプションですか? コピー後のデータが破損する可能性があるかどうかが心配ですが、バグがあることに気付かないのでしょうか?
これまで問題なく使用してきましたが、明らかな何かを見逃していた場合に備えてフィードバックを求めています。
答え1
Robocopy はデータをコピーするための優れたツールです。後で、Beyond Compare などを使用して diff を実行するとよいかもしれません。
データを移動するための他のオプションには、イメージング、Windows レプリケーションなどがあります。ただし、通常は robocopy を使用します。これは、非常に優れたログを作成するためです。
答え2
robocopy は優れたファイル コピー ツールですが、それ自体は最も基本的なバックアップ ツールにすぎません。あなたが言及した検証は良い例です。robocopy には適切なバックアップ ソリューションの一部となる機能がありますが、最適なパラメータや、おそらく 1 つまたは 2 つのラッパー スクリプトを見つけるために、ある程度の時間を費やす覚悟が必要です。
私はこれを頻繁に使用しており、自宅でのアドホックバックアップも含め、気に入っていますが、これは「バックアップ」ソリューションではありません。むしろ、「ああ、台無しにする前にコピーを作成したほうがよい」というソリューションです。
私の.02
答え3
バックアップするコンテンツが何であるか、および RoboCopy が開いているファイルへのアクセスをブロックされる可能性があるかどうかなどによって完全に異なります。
どのようなバックアップ戦略も、バックアップが機能し、完了し、予想した範囲で復元できることを確認するために導入したテスト復元プロセスと同じくらい効果的です。
私は、長年にわたり毎日バックアップ ジョブを実行して成功を報告し、検証してきた多くの場所で働いたことがありますが、復元が必要になったときに、ジョブは機能していたものの、障害が発生したシステムを回復するために必要なすべてのデータが実際には取得されていなかったことが判明しました。
答え4
残念ながら、前の回答には同意できません。robocopy (単体) は、開いているファイルを安全にバックアップするメカニズムがないため、予期しない結果が生じる可能性があるため、データをコピーするための適切なツールではありません。
ここで私が言っているのは理論的な話ではありません。昨年、私の顧客は、データ フォルダーをリモート サーバーと毎日同期するために robocopy を使用していたため、完全なデータ災害 (つまり、何も残らない) に見舞われました。問題のファイルは、大部分がデスクトップ データベース プログラムによって使用されていたため、どのプロセスでファイルがまだロックされていたかによって、正常にコピーされたファイルはランダムでした。
ある従業員が自分の「ライブ」データをすべて削除したとき (理由は聞かないでください)、そのデータを復元するための支援を求めてきました。しかし、「バックアップ」ソリューションが robocopy だったため、私たちには何もできませんでした。
バックアップのルール:
- バックアップする内容を常に考慮してください。
- 展開するときは必ずテストしてください。
- その後は定期的にテストしてください。
- 「テスト」とは、バックアップ ファイル/テープがどこかにあることを確認することではなく、実際にデータを別の場所に復元してデータの整合性をチェックすることを意味します。
- 実行するたびに意味のあるログが作成されることを確認し、誰かがこれらのログをすべてチェックするようにしてください。
残念ながら、robocopy は非常に優れたツールではありますが、上記のことを適切に実行できるプログラムではありません。