☰

(rsync ein) gemountetes Volume: Hardlinks scheinen erhalten zu bleiben, aber der Speicherplatz wird als vollständige Dateien berechnet

tag-icon • tag-icon rsync mount rsnapshot du
(rsync ein) gemountetes Volume: Hardlinks scheinen erhalten zu bleiben, aber der Speicherplatz wird als vollständige Dateien berechnet

Ich versuche, ein platzsparendes rotierendes Backup-Schema mit rsnapshot / rsync von einem Server auf eine Hetzner-Speicherbox einzurichten. Ich habe Schwierigkeiten zu verstehen, wie sich Hardlinks auf dem Ziel auf die gemeldete Festplattennutzung auswirken. Kurz gesagt: Obwohl Hardlinks auf dem Backup-Ziel vorhanden zu sein scheinen, werden sie bei der Festplattennutzung anscheinend nicht berücksichtigt, sondern als vollständige Dateien gezählt.

Da sich der Zielordner von rsnapshot auf dem lokalen Dateisystem befinden muss, habe ich einen Workflow eingerichtet, der aus 2 Teilen besteht:

  1. Erstellen Sie einen lokalen Snapshot mitSchnappschuss, in einem lokalen Ordner auf dem Quellserver
  2. rsync den lokalen Snapshot über SSH mitrsynczum Ziel

Das scheint gut und schnell zu funktionieren, aber ich habe eine Sorge: Die auf dem Ziel (mit ) gemeldete Festplattennutzung du -shscheint die Größe aller Snapshots zu kumulieren,obwohl sie anscheinend ordnungsgemäß mit Hardlinks kopiert wurden. Hinweis: Da Hetzner-Speicherboxen keine interaktive SSH-Anmeldung zulassen, untersuche ich dieses Sicherungsziel als gemountetes Volume mit CIFS.

Beispielsweise enthält der Zielordner nach 3 Runden dieser Kombination aus rsnaphsot und rsync die Ordner daily.0, daily.1, und daily.2. Wenn ich zufällige Dateien in diesen Snapshot-Ordnern auf Hardlinks überprüfe, erhalte ich die erwarteten Ergebnisse:

  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

    gibt 3 Dateien mit identischen Inodes und einer Linkanzahl von 3 zurück (wie erwartet)

  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

    gibt 3 Dateien zurück (wie erwartet)

Ich vermute, dies zeigt an, dass diese Snapshots ordnungsgemäß als Hardlinks zum Ziel kopiert wurden.

Doch... beim Überprüfen der Festplattennutzung am Zielort du -sh /mnt/user.your-storagebox.de/rsync-backupwird ein Wert von 12 G zurückgegeben. Das ist unerwartet, da der ursprüngliche Quellordner nur etwa 4 G groß ist. Offensichtlich wird die Festplattennutzung kumulativ berechnet, trotz der Hardlinks?

Wenn ich andererseits den Zielordner über überprüfe rsnapshot du, erhalte ich die Ausgabe, dasstutscheinen Hardlinks zu berücksichtigen:

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

Das ist verwirrend: Entweder werden die Snapshots mit Hardlinks kopiert und sollten nur minimalen Speicherplatz beanspruchen (was bei der Überprüfung der Inodes der Fall zu sein scheint), oder dies wird nicht getan und sie beanspruchen viel mehr Speicherplatz als erwartet (wie die du -shAusgabe nahelegt).

Meine Hauptsorge ist: Ist die für dieses gemountete Volume gemeldete Datenträgernutzung korrekt oder nicht? Gibt es irgendwelche Einschränkungen in Bezug auf die Nutzung du -shgemounteter Volumes, die ich beachten sollte?

Antwort1

Meine Version von du(Debian, du (GNU coreutils) 8.30) verarbeitet Dateien mit Hardlinks und zählt die mehrfachen Instanzen nur einmal. Es scheint, dass Ihre Version das nicht tut. Sie können dies jedoch ziemlich einfach überprüfen.

Vorbereiten des Szenarios

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

Versuch Nr. 1. Zwei Dateien kopiert, aber nicht fest verknüpft

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"

Versuch Nr. 2. Zwei Dateien fest miteinander verknüpft

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

Wenn Ihre Instanz dunicht mehrere Instanzen derselben fest verknüpften Datei verarbeiten kann, gibt Ihr Versuch Nr. 2 die Summe beider zurück etc.1, etc.2genau wie bei Versuch Nr. 1.

Anhand dieser Informationen können Sie feststellen, ob Ihre Version duirreführend ist oder ob die Dateien tatsächlich mehr Speicherplatz beanspruchen als erwartet. (Angesichts Ihrer anderen Messwerte bin ich ziemlich sicher, dass Ersteres der Fall ist.)

verwandte Informationen