Mike Rubel によって提案された rsync アプローチに従うカスタム バックアップ サービスがあるとします。バックアップ ローテーションを行うには、次のcpコマンドを使用する必要があります。
cp -al source target
これで、たくさんの小さなファイル (~5KB-200KB) を含む 35GB のディレクトリ、つまり非常に大きなツリー ディレクトリをローテーションしようとしています。問題は、それが少なくとも 5 時間続くことです。特に-lオプションを使用することで、私には多くのように思えます。
SATA ディスクでの動作は正常ですか? 組み合わせフラグが原因でcp-alコマンドに余分なオーバーヘッドが発生し、遅延が発生する可能性はありますか?
ありがとう！
ファイルのサイズがすべて約 2 ギガバイトの場合、これは非常に遅いと思います。ファイルのサイズがすべて約 200 バイトの場合、これは高速だと思います。この速度が速いと考える前に、ファイルがどれほど小さくなければならないかは実際にはわかりませんが、ファイルがすべて非常に小さい場合、ドライブはメタデータの検索、読み取り、メタデータの書き込みにほとんどの時間を費やします。ジャーナルのコミットなど。
しかし、どちらにしてもイライラするように聞こえます。
いくつかのアイデアがすぐに思い浮かびます。
a_time何にも使用しない場合は、問題の特定のファイルシステムの稼働時間をオフにすることができますa_time。(ファイルにnoatime mount(8)オプションを追加してくださいfstab(5)。) これにより、コピー操作の「読み取り」側全体に大量の非常に小さな分散書き込みが発生するのを防ぐことができます。これにより、わずかな時間で失敗する可能性があります。5％？10%? おそらくもっとある？mount(8) -oremount,noatimeプラス面は、使用してから見つけるのに数秒かかることです. :)
コピーの代わりにハードリンクを使用できます。(はリンクを使用するためcp(1)のコマンド ライン オプションについて言及してい-lます -- 私は一度も試したことがなく、常に でリンクを作成してきましたが、ln(1)何十万ものファイルに対してリンクを作成するのは面白くないように思えます。 ）ハードリンクを使用する利点は、（a）ディスク容量の節約、（b）ディスク帯域幅の節約です。メタデータのみが読み書きされるため、何千倍も高速になる可能性があります。必要なツールではないかもしれませんが、実際には、バックアップ操作の実行中にアプリケーションがデータをどのように変更するかによって異なります。-lcp(1)
全体のよりスマートな代替品を考え出すことができます。rsync優れたツールですが、最高に優れているわけではありません。git(1)あなたのタスクにとってよりスマートなツールかもしれません。最初にコピーをまったく作成しないと、これははるかに高速になる可能性があります。
たとえば、LVMスナップショットなどの巧妙なブロック デバイス トリックを使用して、バックアップ操作を使用と並行して進め、バックアップが完了したらスナップショットを削除できます。データにあまりチャーンがない場合、これは大幅に高速になるはずです。チャーンが多い場合は、わずかに改善される可能性があります。ただし、5時間のウィンドウの反対側ではなく、すぐにrsyncを開始できます.