Praktische Verwendung von Hardlinks bei Backups

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Moin

    Framp's Rat folgend, im vorherigen Thread nicht zu sehr OT zu werden, öffne ich hier einen neuen Thread. Es ging um die Verwendung von Hardlinks in Backups und in Verbindung mit sync. Mein letzte Frage dort war:

    Ich verstehe nur nicht den Nutzen von Hardlinks in einem Backup. Ich meine, die Verwendung von Hardlinks bei der Erstellung eines Backups oder eines späteren sync's ergeben für mich überhaupt keinen Sinn.
    Also.... ich habe eine zu sichernde Quelle... und nach dem Sichern muss das Backup alle Dateien als Sicherungskopie enthalten. Und wenn ich 2 Wochen später über rsync das Backup mit den auf der Quelle geänderten Files aktualisiere, helfen mir die Hardlinks bei den Dateien, die sich nicht geändert haben doch auch nix. Wenn ich die nicht-geänderten Dateien durch Hardlinks ersetze, habe ich im Backup für diese Files kein Backup mehr, sondern nur noch den Hardlink. Ganz klar, dass das Backup dann gaaaanz klein wird... steht ja auch nix mehr drin, ausser Hardlinks auf die Quellfiles.

    Wo habe ich denn da den Denkfehler? Möglicherweise habt Ihr da noch irgendwas im Hinterkopf, was mir im Moment nicht klar ist oder was ich nicht weiss oder nicht berücksichtige.

    Gruß, Thomas

    Einmal editiert, zuletzt von WinterUnit16246 (6. September 2014 um 11:11)

  • Vielleicht wird es mit einem kleinen Beispiel deutlich:

    1) Es wird ein rsync vorgenommen von einem Verzeichnis SRC welches 3 Dateien A,B und C hat und in das BackupVerzeichnis BU1 geschrieben.
    2) Es wird ein weiteres rsync vorgenommen von dem Verzeichnis SRC in das Verzeichnis BU2. Dabei wird festgestellt, dass keine Datei sich geändert hat und auch keine Datei kopiert. Aber im Verzeichnis BU2 werden drei Hardlinks auf die Dateien in BU1 erstellt.
    3) Es wird die Datei B in SRC geändert und ein weiteres rsync vorgenommen von dem Verzeichnis SRC in das Verzeichnis BU3. Dabei wird festgestellt, dass sich die Datei B geändert hat und wird kopiert. Im Verzeichnis BU3 stehen nun 2 Hardlinks auf die Dateien in BU1 und eine neue Datei B, die sich aber inhaltlich von B in BU1 unterscheidet.
    4) Es wird ein weiteres rsync vorgenommen von dem Verzeichnis SRC in das Verzeichnis BU4. Dabei wird festgestellt, dass sich keine Datei geändert hat zu BU3 und auch keine Datei kopiert. Aber im Verzeichnis BU4 werden zwei Hardlinks für A und C auf Dateien in BU1 erstellt sowie ein Hardlink für B auf BU3.

    Code
    BU1     A  B  C
    BU2     ^  ^  ^
    BU3     ^  B' ^ 
    BU4     ^  ^  ^

    Somit kann man also immer in die jeweiligen BU Verzeichnisse gehen und sieht den Zustand des Backups zu dem Zeitpunkt. Allerdings sind das nicht immer wieder Kopien der Dateien sondern meist nur Links auf Dateien in vorherigen Backups und echte Kopien, wenn sich Dateien geändert haben. D.h. anstatt 4 * (A+B+C) Bytes werden im o.g. Beispiel nur (A + B + C + B') Bytes für das Backup benötigt und ein paar Bytes für die Verlinkung der Dateien.


    Man sieht dass die Dateien A=5, B=9 und C=13 Bytes gross sind. Ab BU3 ist B=59 Bytes gross, weil es eine neue Kopie ist. Die erste Zahl nach den Zugriffsrechten in der Ausgabe gibt die Anzahl der Links auf eine Datei an. D.h. A und C haben 4 Links aus BU1, BU2, BU3 und BU4. B hat jeweils 2 Links aus BU1 und BU2 sowie aus BU3 und BU4.

    Der Parameter -i bei ls zeigt an erster Stelle an auf welche Datei bzw Inode verlinked wird. D.h. Du siehst bei der folgenden Liste dass B zwei Mal auf 1059326 verweist sowie 2 Mal auf 1058870

    EDIT: Dieser Link beschreibt dasselbe noch mal etwas anders und hat zusätzlich zwei Bilder, die die Verlinkung zwischen Inode und Datei zeigen. Auch wird der Unterschied zwischen Soft- und Hardlink erklärt. Ist aber in Englisch.

  • Hallo Framp

    Danke, Du hast Dir wirklich viel Arbeit gemacht, das zu erklären ... :thumbs1: ... und ja, ich glaube, ich habe zumindest jetzt eine Ahnung, was da passiert. Allerdings gestehe ich, dass mich das im Moment sowohl von der Theorie als auch von der Praxis ein wenig überfordert. Ich versuche mal, das mit meinen Worten wiederzugeben, wie ich es verstanden habe:

    1. Ein Datenbestand "SRC" wird in BAK1 gesichert. BAK1 gabs vorher nicht und wird neu erstellt.

    2. Der Datenbestand soll erneut gesichert werden, und zwar mit rsync und nach BAK2. Das Archiv BAK2 gibt es noch nicht und wird neu erstellt. Dabei werden seit BAK 1 in SRC geänderte Dateien vollständig nach BAK2 geschrieben, für unveränderte nur ein Hardlink der Datei aus dem Archiv BAK1

    3. Der Datenbestand soll zum 3. Mal gesichert werden, und zwar wieder mit rsync, nach BAK3. Das Archiv BAK3 gibt es noch nicht und wird neu erstellt. Dabei werden in SRC geänderte Dateien vollständig nach BAK3 geschrieben. Für seit BAK2 unveränderte Dateien entweder ein Hardlink aus BAK1 oder einer aus BAK2, je nachdem, welcher aktueller ist.

    Wenn das so wäre, und ich das so richtig verstanden habe, dann wäre das ein Verfahren, was ich vermutlich nicht anwenden werde.... ganz einfach deshalb, weils mich überfordert. Bei jedem neu zu erstellen BAK müssen ja immer die vorherigen zum Vergleich der Dateistände mit einbezogen werden.

    Ich habe mir auch Dein Script aus Deiner Link-Empfehlung runtergeladen... und alle Achtung... das ist kein Script mehr, das ist schon ein richtigs Programm ....:thumbs1: ... und beim Lesen auf Deiner Seite habe ich auch die Aussagen zur CPU-Last gefunden. Und mein erster Gedanke war "Wieso interessiert ihn das, ob die CPU arbeitet oder nicht?" Ich hab dazu nur eine Erklärung gefunden: Weil sein PI run-um-die-Uhr einen Job hat, der möglichst nicht oder nur sehr wenig von anderen Dingen (z.B. Backup) nachteilig tangiert werden darf.

    Aber genau das gibts bei mir nicht. Mein PI pennt von spätestens 1 Uhr nachts bis zum nächsten Vormittag. Das heisst, wenn ich ihn morgens zwischen 4 und 6 zyklisch Backups erstellen lasse, dann gibts zu keiner Zeit interessenkonflikte mit irgendwelchen anderen Programmen, die wegen des Bak's zuwenig CPU-Zeit erhalten.... das gibts bei mir nicht. Ich habe heute noch mal ein Backup laufen lassen, 92 Minuten hats gedauert....nachts wenn alle schlafen.

    Ich sehe im Moment noch nicht wirkliche Vorteile für mich, wenn ich mich da ins Verstehen und Umsetzen reinkniee und ein so kompliziertes Backup-System einrichte. Ich sehe eher den Nachteil darin, wenn mein Server in absehbarer Zeit mal mannlos läuft und ich mich monatelange nicht drum kümmere, dass ich bei Problemen nicht mehr weiss, wie ich die schwierigen Jobs damals überhaupt konzipiert habe. Ich würde lieber einfach das letzte Full-Bak nehmen, kopiers ohne zu Überlegen auf ne neue Karte und lasse es laufen, wie vorher und gut ist.

    Ich stell mir jetzt gerade die Frage, ob man wirklich immer alles machen sollte, was möglich ist. Zweifelsfrei erfüllt das rsync-BAK höherwertigere Ansprüche. Aber was ich Zuhause mache, ist doch für einen EDV-Profi eigentlich Kinderkram, sowohl vom Equipment, als auch von der Infrastruktur, der Relevanz meiner Daten, der Anzahl der User und Clients. Die Frage ist, ob nicht für meine Anforderungen und Bedürfnisse etwas Weniger in Wirklichkeit Mehr ist.

    :s

    Gruß, Thomas

    Einmal editiert, zuletzt von WinterUnit16246 (6. September 2014 um 16:15)

  • Jupp, Du hast es verstanden :bravo2:

    Mit rsync wird die CPU wie auch die SD Karte am meisten geschont. Deshalb bevorzuge ich das Verfahren. Ich hatte Dich auch so verstanden, dass Du gerne noch in die Backups reinsehen willst und auf Teile zugreifen willst. Wenn es wirklich nur als Backup gedacht ist und Dich die lange Backupzeit wie auch CPU- und SD Kartenbelastung nicht stört ist tar bzw tgz wohl doch eher die bessere Lösung für Dich. Jeder hat andere Ansprüche an ein Backup und sollte natürlich die für ihn optimalste Lösung wählen :)

    BTW: Das Backupscript sorgt automatisch dafür dass immer auf den letzten Backup gesynced wird. Darum musst DU Dich nicht kümmern.

  • Ja, mal öffnen und reinschauen....aber das ist anscheinend nicht möglich. Das öffnende Programm muss sich ja die gesamte im Bak gespeicherte Linux-Verzeichnis-Struktur des Pi reinziehen und zur Darstellung speichern... viel zu viele Dateien, zu grosses Archiv und dann noch komprimiert.

    Würde ich unkomprimiert speichern, wird das vielleicht gehen. Aber dann ist das Backup 3 mal so gross, statt. 1,7 GB dann 5 GB.

    Und wie ich schon mehrfach gesagt habe, meine SD-Karte hat nix damit zu tun. Die Backups gehen auf eine Platte. Auf der Karte passiert nix ....sofern nicht geswappt wird .... was ich nicht hoffe.

    Mit rsync wird die CPU wie auch die SD Karte am meisten geschont.

    Welchen Vorteil hat das, wenn er sowieso in dem Moment nix tut? Der Prozessor altert doch nicht weniger, wenn man ihn schont ....?... oder mehr und schneller, wenn er arbeitet?

    Gruß, Thomas

    Einmal editiert, zuletzt von WinterUnit16246 (6. September 2014 um 17:02)

  • ...Welchen Vorteil hat das, wenn er sowieso in dem Moment nix tut? Der Prozessor altert doch nicht weniger, wenn man ihn schont ....?... oder mehr und schneller, wenn er arbeitet?...

    Bin eben mal wieder über diesen Thread gestolpert und irgendwie ist Deine Antwort an mir vorbeigegangen :-/
    Du hast natürlich Recht. Aber wenn Du schlechte CPU Kühlung hast oder auch übertaktet hast wird sie bei zu heftiger Beanspruchung u.U. zu warm und kommt in den Bereich ausserhalb der Betriebstemperatur. Dann wird Deine Pi intermittierend abstürzen oder auch je nach Temperatur die CPU 'abrauchen'. Mit

    Code
    watch -g vcgencmd measure_temp

    kannst Du Dir Deine CPU Temperatur ansehen.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!