現在、システムのバックアップパフォーマンスを向上させる方法を探しており、一部のテストでは次のような結果が得られています。
圧縮されていないTARを使用してUbuntuシステムをSSDからHDD（ext4のすべて）にバックアップすることは、同じコンテンツをSSDからHDDに同期するよりもはるかに高速です。
詳細：
TAR1h 15min429Gの大容量ファイルの取得と生成rsync5h大きな406Gフォルダを撮影して作成する
両方のツールで使用されている無視ファイルの内容が同じで、両方のツールに対してわずかに調整されているため、同じデータをコピーする必要があります。
最終的なTARが実際にrsyncedフォルダより大きい理由はよくわかりませんが、ATMにはあまり興味がありません。
私が本当に興味を持っているのはTARはなぜそんなに速いのですか？＆私ができるなら何らかの方法でrsyncを改善してください。（または他のファイルコピーツール）同様のパフォーマンスを得るには？
私はTARをバックアップ戦略として使用したくありません。これは、大きなアーカイブを解凍したり、単一のファイルを抽出するのに「長い時間」がかかり、実際にアクセスする必要がある場合に問題になる可能性があるためです。
常に同じターゲットフォルダにコピーすると、rsyncのパフォーマンスが大幅に向上する可能性があることに気づきました。増分コピーしかし明らかです。私が探しているものではありません。なぜなら、常に異なる日付の複数のバックアップをしたいからです。
アップデート、追加情報
代替「TARによるコピー」テスト
私も「TAR経由でコピー」を試しました。ここまたはここ）はrsyncより少し遅いので、ボトルネックは書き込み速度のようです。
使用されるコマンド
上記の結果を得るために、次のコマンドを使用しました。
tar -X "tar-excludes.txt" -cvf "/media/backup/full" "/"rsync -aAXWvh --stats --info=progress2 --exclude-from "rsync-excludes.txt" --log-file="log.txt" "/" "/media/backup/full"
文書
オペレーティングシステム全体（一部の例外を含む）をバックアップするため、バックアップにはすべての種類のファイルが含まれます。いくつかの大きなファイルと多くの小さなファイル。
デバイスの詳細
ホストはIntel NUC D34010WYKH〜8年の製品です。
ソースドライブは内部SSDで、ターゲットドライブはUSB 3.0を介して接続された外部HDDです。両方のドライブが使用されますext4。
答え1
さまざまな cpio および tar ファイル形式は、ファイルヘッダーとファイルデータの簡単な順序です。新しいファイルヘッダーを作成すると、レコードが出力ファイルに追加されます。ファイルデータを作成すると、出力ファイルにさらにレコードが追加されます。
これが起こる唯一のことです。レコードが出力ファイルに追加されます。多くの場合、これらのレコードは10KiBまたは5KiB（場合によっては1MiB）チャンクでバッチされます。
これは非常に効率的な作業です。出力ファイルが実際の場合テープ装置これは単にテープの現在の位置に書き込み（順次出力）を追加するだけです。これは驚くべきことではありません。これらのユーティリティはファイルをテープに保持するように設計されており、順次I / O属性は良好で、ランダムアクセスI / O属性は悪いです。
（圧縮を追加してもこの内容は変わりません。圧縮ユーティリティも順次I / Oを使用するように設計されています。）
これがディスクボリューム上のファイルであっても、レコードの各追加バッチは本質的に3つの作業です。つまり、別のブロックを取得するためにディスクボリュームの空き領域マップを調整し、ファイルの末尾に対応する新しいブロックを含めるようにファイルinodeを調整します。ファイルシステムがコストを削減できる範囲と適切な割り当て戦略を使用してブロックを作成します。これは、順次追加の書き込みパターンが検出されたときに連続データブロックの実行を推論的に事前割り当てする一般的なファイルシステムドライバの最適化を使用すると、実際に非常に安価に実行できます。
rsyncバックアップは、ディレクトリエントリの作成、Bツリーの更新などを含むツリー全体をディスクボリュームに作成し、iノード割り当て、ハードリンク作成、およびすべてのログ更新を作成します。またディスクボリュームの空き領域マッピングの調整、inodeのブロック割り当ての調整、ファイルデータのブロック書き込みなど、個々のファイルレベルでcpio / tarアーカイブを操作します。
順次追加操作のみを使用してアーカイブを作成することはテープにとって非常に効率的であり、ディスクボリュームに格納されている単一のアーカイブファイルにも非常に効率的です。多数の個別ファイルを作成するには、本質的に多くの作業が必要です。
もちろん、これらの効率のために支払う対価は、アーカイブの簡単なインライン修正、優れたアーカイブランダムアクセス読み取り、スマート増分バックアップ機能です。
1980年代に、Rahul Dhesiはアーカイブ形式を作成しました。最大Serial（シリアル）は、少量のランダムアクセス I/O を使用して既存のアーカイブへのインライン更新を可能にし、置き換えられたファイルのヘッダーを上書きします。欠点は、アーカイブ全体を書き換えて置き換えられたファイルのファイルヘッダーとデータを頻繁に削除する必要があります。
答え2
TARは429Gの大容量ファイルを生成するのに1時間15分かかりました。
rsyncは5時間かかり、406Gの大容量フォルダを作成します。
水晶玉を見ながらいくつかの推論をすることができます。小さなファイルが多く、ソースデバイスとターゲットデバイスの間にかなりの待ち時間があるということです。これらの要因を見て、問題で見つかったものとバックアップを作成するために実行した実際のコマンドを含めると便利です。
Tarは次の理由ではるかに高速です。
- データトラフィックは一方向にのみ流れ（おそらく）接続を飽和させることができます。 - OTOH rsyncは両端で同時にデータを取得する必要があります。
- tar は単一ストリームに書き込むため、ファイルの生成には影響しません。
常に同じターゲットフォルダにコピーして増分コピーを取得することでrsyncのパフォーマンスを大幅に向上させることができますが、常に別の日付の複数のバックアップをしたいので、これは明らかに私が望むものではありません.
ソースとターゲットが同じホスト（agan、指定されていない）に接続されているブロックデバイスであると仮定すると、ファイルシステムを上書きする必要があります。
答え3
これはcentos /ディレクトリです（ここでは重要ではありません）。
bin boot dev etc home lib lost+found media mnt opt proc root sbin selinux srv sys tmp usr var
/dev、/proc、および/sysをコピーしたくない可能性が高く、必要に応じて/mediaもコピーしたくない場合があります。
したがって、使用する代わりにrsync / $DEST（$ DESTが別のホストにあるとします）。
君は走れるよ
rsync /bin /boot /etc /lib /root /sbin /selinux $DEST &
sleep 300
rsync /home $DEST &
sleep 300
rsync /opt $DEST &
...
wait
すべてのデータが/ homeにある場合は、読み続けることができます。
rsync /home/dir1 $DEST &
sleep 300
rsync /home/dir2 $DEST &
...
$DESTを調整するか、除外オプションを使用する必要があります。rsync
1,000,000個のファイルがあると仮定すると、rsync（s）はまだ1Mファイル統計（ソース部分）と1Mファイル統計（ターゲット部分）を確認して圧縮などを実行する必要があります。
コメントで述べたように、1億のファイルを含むディレクトリを1日に2回同期する必要があり、rsyncは14〜16時間続きます。上記の戦略（そしていくつかの試行錯誤）を使用して時間を4〜16時間に短縮することができました。 5時間、20個のrsyncを使用（そのうち15個は一時）