Ubuntu 10.04 LTSセットアップでrsyncを使用してLARGEホームディレクトリをバックアップするときに転送されるファイル数が大幅に不足する一般的な理由を知っている人はいますか?マシンは安定しており、すべてのボリュームはクリーンなext4です-fsck.ext4からのエラーはありません。
Number of files: 4857743
Number of files transferred: 4203266
それは654,477ファイルの違いです!!!
完全なホームフォルダーを外部ディスクにバックアップして、システムを完全にワイプして再フォーマットし、このrsyncでバックアップしたバックアップから家を復元したいのですが、重要なデータファイルが見つからないのではないかと心配しています。
Rootとしてログインし、rsyncを使用して/ home/hholtmann/*ディレクトリを/ mnt/wd750/c51/home /のスペアバックアップドライブにバックアップしました
ここに私がルートとして使用したコマンドラインがあります
root@c-00000051:~# pwd
/root
root@c-00000051:~# rsync -ah --progress --stats /home/hholtmann /mnt/wd750/c51/home/ -v
Rsyncからキャプチャされた要約出力
Number of files: 4857743
Number of files transferred: 4203266
Total file size: 487.41G bytes
Total transferred file size: 487.41G bytes
Literal data: 487.41G bytes
Matched data: 0 bytes
File list size: 102.48M
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 487.75G
Total bytes received: 82.42M
Rsyncの後で私の家の重要なプロジェクトのサブディレクトリを比較するだけです:
du
を使用したソースと宛先のサブディレクトリ間のバイトの違い
root@c-00000051:~# du -cs /home/hholtmann/proj/
18992676 /home/hholtmann/proj/
18992676 total
root@c-00000051:~# du -cs /media/wd750/c51/home/hholtmann/proj/
19006768 /mnt/wd750/c51/home/hholtmann/proj/
19006768 total
ただし、同じソースと宛先のサブディレクトリ間でファイルカウントに違いはありません
root@c-00000051:~# find /home/hholtmann/proj/ -type f -follow | wc -l
945937
root@c-00000051:~# find /mnt/wd750/c51/home/hholtmann/proj/ -type f -follow | wc -l
945937
なぜそのような予期せぬ結果なのか?ファイルとは、特にユーザーのホームディレクトリにあるファイルです。
何が欠けていますか?またはこれは私が管理の準備ができている兆候ですか?
解決策と回答:
以下の選択された回答は、バイト数の違いと、rsync要約データに対する私の誤った期待について説明しています。両方のボリュームがデフォルトのブロックサイズのext4であることを考えると、このバイトの違いに驚きました。私は、すべてのファイルがdu
数に関して同じスペースを取ると仮定しました。
I DIDrsync'dでなかったいくつかのファイルを見つける-vv
をrsyncに戻して再度実行します。
私が見たのは、ファイルの「拡張属性」が原因で、DROPBOX dirファイルを宛先に書き込めなかったというrsyncのエラーです。 rsyncがすべてのドロップボックスパスファイルをスキップしていました。
/ etc/fstabファイルのuser_xattr
ext4マウントオプションでマウントされた/ homeボリュームが終了します。
/dev/mapper/vg1-lv_home /home ext4 nobarrier,noatime,user_xattr 0 2
# I HAD to add the ,user_xattr option to match my home volume
/dev/sda1 /mnt/wd750 ext4 nobarrier,noatime,user_xattr 0 2
3回目のフルrsyncをもう一度実行した後、フルホームフォルダーとrsyncされたバックアップでファイルカウントを一晩中実行することにしました。
root@c-00000051:~# find /home/hholtmann/ -type f | wc -l
4203266
root@c-00000051:~# find /mnt/wd750/c51/home/hholtmann/ -type f | wc -l
4203266
**ファイルの完全一致**
結論:
**バックアップボリュームがソースとまったく同じファイルシステムマウントオプションでマウントされていることを常に確認し、rsyncで完全なロギングをオンにして、後のgrep分析で長いファイルリストのエラーを検索してください! **
この質問には2つの部分があります。まず、「ファイル数」と「転送ファイル数」に違いがあるのはなぜですか。これは、rsyncマンページで説明されています。
ファイル数:(一般的な意味での)すべての「ファイル」の数で、ディレクトリ、シンボリックリンクなどが含まれます。
転送されたファイルの数:rsyncのデルタ転送アルゴリズムを介して更新された通常のファイルの数です。これにはnotが含まれます作成されたディレクトリ、シンボリックリンクなど。
ここでの違いは、ディレクトリ、symnlinks、その他の特殊ファイルの総数と等しくなければなりません。それらは「転送」されず、再作成されただけです。
さて、第2部では、なぜduとサイズの違いがあるのでしょうか。 duは、ファイルのサイズではなく、ファイルが使用するディスク容量を示します。たとえば、ファイルシステムのブロックサイズが異なる場合、同じファイルが異なるディスク容量を占める可能性があります。
それでもデータの整合性が心配な場合は、すべてのファイルのハッシュを作成して比較することで簡単に確認できます。
( cd /home/hholtmann && find . -type f -exec md5sum {} \; ) > /tmp/hholtmann.md5sum
( cd /media/wd750/c51/home/ && md5sum -c /tmp/hholtmann.md5sum )
真夜中の休暇から働いている他のすべての貧しい失われた魂に、
--checksum
は、rsyncにファイルに変更があるかどうかを実際に確認させます。それ以外の場合は、タイムスタンプとファイルサイズを確認し、1日と呼びます。
これは99.9%のケースで十分であり、これを理解するまで、残りの0.01%を地獄で燃やすことができます。
以下を試してみてください、これはあなたを助けるかもしれません、
rsync -avH --delete /home/hholtmann/ /media/wd750/c51/home
私が学んだことを追加することもできます。
コマンドrsync /path/source/* /path/to/destination/*
を使用していました(グロビングに注意してください)。私のファイルの90%がいくつかの例外を除いて転送されていた(転送を行ったフォルダーと同じフォルダーにさえある)ため、これは厄介でした。ソースと宛先から*
を削除した後、それらはすべて転送されました。 ¯\ _(ツ)_ /¯