(rsync オン) マウントされたボリューム: ハードリンクは保持されているようですが、スペースは完全なファイルとして計算されます

Question

私は、サーバーから Hetzner ストレージボックスへの rsnapshot / rsync を使用して、スペース効率の高いローテーション バックアップ スキームを設定しようとしています。バックアップ先のハード リンクが、報告されるディスク使用量にどのように影響するのか理解するのに苦労しています。簡単に言うと、バックアップ先にハード リンクがあるように見えますが、ディスク使用量には考慮されず、完全なファイルとしてカウントされるようです。

rsnapshot の保存先フォルダーはローカル ファイル システム上にある必要があるため、次の 2 つの部分で構成されるワークフローを設定しました。

1. ローカルスナップショットを作成するスナップショットソースサーバーのローカルフォルダ内
2. SSH経由でローカルスナップショットをrsyncするrsync目的地まで

これはうまく高速に動作するようですが、1つ懸念があります。宛先で報告されるディスク使用量（du -sh）は、すべてのスナップショットのサイズを累積しているようです。ハードリンクを使用して適切にコピーされているように見えるにもかかわらず注: Hetzner ストレージボックスでは対話型 SSH ログインが許可されていないため、このバックアップ先を CIFS でマウントされたボリュームとして検査しています。

たとえば、この rsnaphsot + rsync の組み合わせを 3 回実行すると、宛先フォルダーにはdaily.0、、daily.1およびdaily.2フォルダーが含まれます。これらのスナップショット フォルダー内のランダム ファイルにハード リンクがあるかどうかをチェックすると、期待どおりの結果が得られました。

1. find /mnt/user.your-storagebox.de/rsync-backup/ -name "output.file" -print0 | xargs -0 ls -li:

   351317 -rw-rw---- 3 root root 8650 Dec 15 11:25 /mnt/user.your-storagebox.de/rsync-backup/daily.0/home/user/output.file
   351317 -rw-rw---- 3 root root 8650 Dec 15 11:25 /mnt/user.your-storagebox.de/rsync-backup/daily.1/home/user/output.file
   351317 -rw-rw---- 3 root root 8650 Dec 15 11:25 /mnt/user.your-storagebox.de/rsync-backup/daily.2/home/user/output.file
   

   同一の inode を持つ 3 つのファイルと、リンク数が 3 である (予想どおり) を返します。

2. find /mnt/user.your-storagebox.de/rsync-backup/ -samefile /mnt/user.your-storagebox.de/rsync-backup/daily.0/home/user/output.file

   /mnt/user.your-storagebox.de/rsync-backup/daily.0/var/tomcat/vhosts/output.file
   /mnt/user.your-storagebox.de/rsync-backup/daily.2/var/tomcat/vhosts/output.file
   /mnt/user.your-storagebox.de/rsync-backup/daily.1/var/tomcat/vhosts/output.file
   

   3 つのファイルを返します (予想どおり)

これは、これらのスナップショットがハードリンクとして宛先に適切にコピーされたことを示していると思います。

しかし... 宛先の場所のディスク使用量をチェックすると、du -sh /mnt/user.your-storagebox.de/rsync-backup12G の値が返されます。元のソース フォルダーは約 4G しかないため、これは予想外です。どうやら、ハード リンクにもかかわらず、ディスク使用量は累積的に計算されるのでしょうか?

一方、経由で宛先フォルダを調べるとrsnapshot du、次のような出力が得られます。するハードリンクを考慮しているようです:

4.3G    /mnt/user.your-storagebox.de/rsync-backup/daily.0/
41K     /mnt/user.your-storagebox.de/rsync-backup/daily.1/
41K     /mnt/user.your-storagebox.de/rsync-backup/daily.2/
4.3G    total

これは紛らわしいものです。スナップショットがハードリンクでコピーされていて、最小限のスペースしか占有しないか (inode を検査するとそのように見える)、そうではなく、予想よりもはるかに多くのスペースを占有しているか (出力からわかるようにdu -sh) のいずれかです。

du -sh私の主な懸念は、このマウントされたボリュームで報告されたディスク使用量が正しいか間違っているかということです。マウントされたボリュームの使用に関して注意すべき注意事項はありますか?

Answer 1

私のバージョンのdu（Debian、du (GNU coreutils) 8.30）はハードリンクのあるファイルを処理して、複数のインスタンスを1回だけカウントします。あなたのバージョンではそうではないようです。これはかなり簡単に確認できますが、

シナリオを準備する

mkdir zzz                 # Scenario workspace
tar cf zzz/etc.1 /etc     # Ignore "tar: Removing leading `/' from member names"

トライアル #1。2 つのファイルをコピーしたがハードリンクされていない

cp zzz/etc.1 zzz/etc.2    # Create copy

du -s zzz/etc.1           # 2580 KB, in my instance
du -s zzz/etc.2           # As you would expect, the same value
du -s zzz                 # 5164 KB, because the files are "different"

トライアル #2。2 つのファイルをハードリンクする

rm zzz/etc.2
ln zzz/etc.1 zzz/etc.2    # Create hardlink

du -s zzz/etc.1           # Unchanged from above, of course, 2850 KB
du -s zzz/etc.2           # As you would expect, still the same value
du -s zzz                 # For me, this is still the same value, 2580 KB

のインスタンスが同じハードリンクされたファイルの複数のインスタンスを処理できない場合、試行 #2 は試行 #1 と同様に、duと の合計を返します。etc.1etc.2

この情報を使用すると、 のバージョンduが誤解を招くものなのか、それともファイルが予想以上に多くのディスク領域を使用しているのかを判断できます。(他の指標を考慮すると、前者であることはほぼ間違いありません。)