複雑

アスファルト

ssh root@main_server "tar czf - /DB_TABLES" |tar xzf - -C /bck

（z以前のコメントfでも指摘してf -抽出しましたtar）

リモートからmain_serverローカル/bckディレクトリにファイルを転送すると、/DB_TABLESファイルが小さくないため、転送が完了すると一部のファイルが変更され、途切れることが/bckあります。

同期

rsync --archive --verbose --relative --delete root@main_server:/DB_TABLES/ /bck

少し良いことは、rsyncファイルが両側から収集され、新しいファイルまたは変更されたファイルが転送されることです。すべてのファイルは初めてrsync送信されます。その後、より小さいボリュームが転送されることを望みますが、収集フェーズ後にファイルが変更されると、ファイルは/DB_TABLES失われます（転送されないなど）。

小さなファイルが多い場合は、並列に実行できます。 (1)

rsync --archive --verbose --relative --delete root@main_server:/DB_TABLES/dir1/ /bck
rsync --archive --verbose --relative --delete root@main_server:/DB_TABLES/dir2/ /bck
(...)

（1）正しい構文を保証することはできません。

データベース

/DB_TABLES転送中にファイルが変更されないようにする必要があります（ssh+tarどちらかrsync）。これが可能な場合（データベースを停止するなど）、2つの解決策のうちの1つが機能します（rsync長期的には高速です）。

rsyncデータベースの停止/停止にかかる時間を確認するためにかかる時間を修正できます。

データベースを停止できない場合は、提供されている場合はリモート同期メカニズム（ログ転送、スレーブ）を使用してください。

牙

費用がかかりますが、効果的な解決策は実際にデータを回復することです（たとえば、ローカルコピーを作成し、最近挿入されたレコードを検索するなど）。これには多くのリソースと人員が必要であり、実際に生産を中断する1つ以上のデータベースを含めることもできます。理想的には、このテストを毎年/四半期ごとに実行する必要があります。