Hallo allerseits,
beim Stammtisch am Mittwoch hatte ich gefragt, wie man bei zwei externen Backup-Festplatten idiotensicher feststellen kann, welches Backup das aktuelle ist.
Mit git und anschließendem Rückgriff auf die ctime von .git/index sollte dabei nicht gearbeitet werden, weil git für Bild- und pdf-Dateien weder gedacht noch gemacht ist.
Mit find ... -newer oder anderen Command Flags wollte ich nicht arbeiten, da ich einen mehrfachen, iterativen Aufruf von find befürchtete.
Also habe ich mir folgendes zusammengebastelt: #!/bin/bash HDA=$(sudo ls -aclR --time-style=long-iso /Pfad/zu/HDA | grep -v :$ | grep -v " .."$ | tr -s " " | cut -d" " -f6-7 | grep -v ^$ | sort -ur | head -1) HDB=$(sudo ls -aclR --time-style=long-iso /Pfad/zu/HDB | grep -v :$ | grep -v " .."$ | tr -s " " | cut -d" " -f6-7 | grep -v ^$ | sort -ur | head -1) if [[ $HDA < $HDB ]] ; then echo "HDB (Label=...) ist aktuell" # Backup entsprechend ausführen else echo "HDA (Label=...) ist aktuell" # Backup entsprechend ausführen fi exit
und möchte das kurz kommentieren: sudo ... Alle Verzeichnisse auf der Backup-Festplatte sollen ohne Fehlermeldung durchsucht werden. ls -a ... auch "versteckte" Verzeichnisse und Dateien berücksichtigen -c ... ctime ausgeben, was -l voraussetzt -l ... s. unter -c -R ... rekursiv vorgehen (alle Unterverzeichnisse berücksichtigen) --time-style=long-iso ... gibt eine ctime analog zu "2023-10-27 10:44" (ohne die "") aus grep -v :$ ... die "Überschriften" der Unterverzeichnisse werden nicht gebraucht grep -v " .."$ ... die ctime der jeweils übergeordneten Verzeichnisse werden nicht gebraucht, da sie bereits durch ls -R erfaßt wurden. Zugleich wird eine irreführende ctime herausgeworfen: Wenn HDA für das Backup als /Pfad/zu/HDA eingehängt wird, erhält /Pfad/zu als ctime Einhängedatum und -zeit von HDA. (Analog bei HDB.) Auf *das Einhängen* der Backup-Festplatte aber kommt es nicht an – es wäre sogar irreführend, wenn die aktuelle Backup-Platte als erste und die zu aktualisierende Platte als zweite (damit neuer) im selben Verzeichnis (bei externen Festplatten meist /media/<username>/) eingehängt wird. tr -s " " ... mehrfache Leerzeichen wie in drwx------ 3 root root 4096 2019-07-04 13:37 .dbus -rw-r--r-- 1 jm jm 26 2023-08-04 16:24 .dmrc zu einem zusammenziehen: drwx------ 3 root root 4096 2019-07-04 13:37 .dbus -rw-r--r-- 1 jm jm 26 2023-08-04 16:24 .dmrc Schließlich soll der folgende cut-Befehl ja funktionieren. cut -d" " -f6-7 ... Nachdem die Felder nur noch durch jeweils ein Leerzeichen voneinander getrennt sind, ctime (Datum und Uhrzeit) extrahieren grep -v ^$ ... Leerzeilen wegwerfen sort -u ... mehrfach auftretende Zeilen nur einmal ausgeben (könnte eigentlich entfallen, fällt mir gerade auf) -r ... die Zeile mit der "größten" (neuesten) ctime als erste ausgeben und ... head -1 ... nur diese Zeile mit der "größten" (neuesten) ctime ausgeben
[[ $HDA < $HDB ]] ist ein lexikalischer Vergleich: Die spätere ctime ist die größere, und die eigentlichen Backup-Befehle habe ich hier weggelassen.
Kommentare sind selbstverständlich erwünscht.
Viele Grüße und schon einmal ein schönes Wochenende Jakob
Hallo zusammen,
in letzter Zeit habe ich mich auch intensiv mit dem Thema Backup auseinandergesetzt und dabei bin ich auf ZPAQ gestoßen. ZPAQ ist ein robustes Datenformat mit offener Spezifikation, welches Deduplikation, Journaling (Versionierung) und Verschlüsselung (AES) bietet. Die gleichnamige Referenzimplementierung "zpaq" vereint diese Fähigkeiten in einem kompakten und portablen Tool. Mit zpaq konnte ich zahlreiche komplexe Skripte ersetzen. Ich denke, dass mein Beitrag hier vielleicht für einige von Interesse sein könnte.
Das ursprüngliche ZPAQ-Projekt[1] ist mittlerweile etwas veraltet, insbesondere da SHA-1 nicht mehr als sicher angesehen wird. Es gibt jedoch einen Fork[2], der versucht, einige Verbesserungen einzuführen.
ZPAQ spielt eine entscheidende Rolle in meiner Backup-Strategie. Neben den stündlichen lokalen ZFS-Snapshots mit Sanoid und den wöchentlichen Full-System-Backups mit ZFS Send auf einem externen USB-RAID stellt ZPAQ die dritte Sicherungsebene dar. Diese Ebene ist dafür gedacht, alle Nutzdaten vor Datenverlust bei katastrophalen Ereignissen wie Naturkatastrophen oder Elementarschäden zu schützen. Ich verwende mobile USB-Festplatten als Datenträger, die rotierend verwendet und teilweise geografisch verteilt gelagert werden. Die Sicherung erfolgt automatisch per Cron-Job jede Stunde, wobei jeder Datenträger ein "label"-File mit einer UUID besitzt. So wird erkannt, ob der Datenträger zwischenzeitlich gewechselt wurde. Nach einem Wechsel werden die veralteten Archive gelöscht und ein vollständiges Backup erstellt. Wenn kein Wechsel stattgefunden hat, werden geänderte Daten als neue Version an die bestehenden Archive angehängt. Dies wird von einem einfachen Shellscript gesteuert, das nicht der Rede wert ist.
Während dieses Prozesses habe ich auch ein Problem gelöst, das viele Unix/Linux-Enthusiasten bei der Verwaltung ihrer Heim-IT oft übersehen, so wie es bei mir bis vor Kurzem der Fall war: "Was passiert eigentlich, wenn der 'Administrator' nicht verfügbar ist, der Server ausfällt und ein Familienmitglied dringend auf wichtige Daten zugreifen muss?" Auf den mobilen Festplatten befinden sich nun ZPAQ-Backups aller Netzwerklaufwerke und Datenbanken. Die Festplatten sind im exFAT-Format formatiert, und neben den Archivdateien sind auch statisch verlinkte Binaries des ZPAQ-Programms für Windows, FreeBSD und Linux sowie eine Kurzanleitung als Textdatei enthalten. Dank exFAT kann von nahezu jedem gängigen Betriebssystem problemlos darauf zugegriffen werden, wodurch eine entscheidende Hürde genommen wird.
Viele Grüße & schönes Wochenende Matthias
[1] https://mattmahoney.net/dc/zpaq.html [2] https://github.com/fcorbelli/zpaqfranz
On 27.10.23 13:32, Jakob Mendel wrote:
Hallo allerseits,
beim Stammtisch am Mittwoch hatte ich gefragt, wie man bei zwei externen Backup-Festplatten idiotensicher feststellen kann, welches Backup das aktuelle ist.
lug-dd@mailman.schlittermann.de