staging.inyokaproject.org

Hallo,

ich bin ein Freund der 1:1-Kopie für Backups und verwende seit Ewigkeiten folgende Befehle, in dem ich das Änderungsdatum als Markierung für bereits gesicherte Daten verwende:

find /home/norfolk/data/. -type f -newermt "2007-01-01 1:11:11" | cpio -pd /home/norfolk/exthdd/backup 
find /home/norfolk/data/. -type f -newermt "2007-01-01 1:11:11" -print0 | xargs -0 touch -d '2007-01-01 1:11:11'

find /home/norfolk/data/. -type f -newermt "1970-01-01 0:00:01" ! -newermt "2007-01-01 1:11:10" | cpio -pd /home/norfolk/exthdd/backup
find /home/norfolk/data/. -type f -newermt "1970-01-01 0:00:01" ! -newermt "2007-01-01 1:11:10" -print0 | xargs -0 touch -d '2007-01-01 1:11:11'

Das funktioniert für mich ausreichend gut, hat aber den Schwachpunkt, dass das (1) find|cpio und das (2) find|touch nacheinander für alle gefundenen Dateien durchlaufen. Wenn sich zwischen den Läufen von (1) und (2) Dateien ändern, wird das also nicht mehr erkannt und die Datei fälschlich bei (2) als gesichert markiert. Und der Worst-Case-Fail: Wenn (1) abbricht, ist es i.A. nicht mehr möglich, die bereits übertragenen Daten zu identifizieren.

Ich möchte den Ablauf so ändern, dass für jede Datei direkt nach dem "cpio" ein entsprechendes "touch" erfolgt.

Leider ist mein Wissen da am Ende. Ich kann zwar rudimentär mit find umgehen und habe auch z.B. mit "find (...) -exec bash" ein Scriptlet gestartet, aber primär auf dem Niveau "ähnliche Beispiele umbauen" - davon bin ich hier auch wegen dem mit/ohne xargs eher weit entfernt und freue mich über jeden Tipp.

Lg, Norfolk

ich bin ein Freund der 1:1-Kopie für Backups [...]

Sehe ich das richtig, daß du den gesicherten Dateien einen neuen Zeitstempel verpasst? Völlig unnötig.

• Für eine 1:1-Kopie würede ich rsync nehmen. Damit kannst du in der Quelle geänderte Dateien auch im Ziel löschen.

  rsync --verbose --update --recursive --times --delete "$quellordner" "$zielordner/"

• Für ein Kopieren nur neuerer Dateien ohne Löschen im Ziel reicht auch ein simples cp:

  cp --verbose --update --preserve=timestamps --recursive "$quellordner" "$zielordner/"

Ja, und ich bin nicht sicher ob dein Weg für meinen Fall funktioniert.

Anwendungsbeispiel: Am Produktivsystem liegen 10 Dateien. Davon sind 7 Dateien bereits auf HDD_1 gebackupped, die keinen weiteren Speicherplatz aufweist. Weitere Daten müssen daher auf HDD_2 gesichert werden, die bisher leer ist.

Über den Timestamp erkenne ich die 7 bereits gesicherten und weiterhin unveränderten Dateien. Damit können die 3 noch ungesicherten, sowie eventuell geänderte Daten auf die neue, leere HDD_2 gesichert werden.

dingsbums schrieb:

Sehe ich das richtig, daß du den gesicherten Dateien einen neuen Zeitstempel verpasst? Völlig unnötig.

Das ist nicht nur unnötig sondern fehlerträchtig!

• Für eine 1:1-Kopie würede ich rsync nehmen. Damit kannst du in der Quelle geänderte Dateien auch im Ziel löschen.

  rsync --verbose --update --recursive --times --delete "$quellordner" "$zielordner/"

Bei rsync sollte man die Option "--link-dest=DIR" nutzen um nicht unnötig viel Platz zu verschwenden. Viel besser ist allerdings ein dafür gebautes Programm wie BorgBackup zu nutzen.

Norfolk schrieb:

Anwendungsbeispiel: Am Produktivsystem liegen 10 Dateien. Davon sind 7 Dateien bereits auf HDD_1 gebackupped, die keinen weiteren Speicherplatz aufweist. Weitere Daten müssen daher auf HDD_2 gesichert werden, die bisher leer ist.

Über den Timestamp erkenne ich die 7 bereits gesicherten und weiterhin unveränderten Dateien. Damit können die 3 noch ungesicherten, sowie eventuell geänderte Daten auf die neue, leere HDD_2 gesichert werden.

Ich fände das extrem unpraktisch ein Backup so über mehrere Platten zu verteilen, weil man da immer manuell Hand anlegen muss. Tue Dir den Gefallen und nutze ein richtiges Backup-Programm. Mit Borg ist es auch sehr einfach Backups im Laufe der Zeit auszudünnen. Außerdem unterstützt es Deduplikation und Kompression und Du kannst sogar alle Backups mounten und in Ruhe anschauen oder Dateien wiederherstellen. Ich hänge mal zur Anschauung mein Backup-Skript an.

Wenn Du aus irgendwelchen Gründen mehrere Platten brauchst, dann könntest Du darüber nachdenken, die mit btrfs zu formatieren und zu einem Volume zusammen zu fassen.

Ok, vielleicht war der Begriff "Backup" auch ungünstig gewählt. Mir ist durchaus bewusst, dass es nicht ein Backup im klassischen Sinn ist.

Ich verwende mein System seit ca. 27 Jahren im privaten Bereich, um praktisch alle Daten doppelt und offline abzulegen, nachdem ich in den Jahren auch ca. 10 HDD-Ausfälle erlebt habe. Der älteste aktive Datenträger ist 9 Jahre alt, vor Kurzem wurde einer nach 13 Jahren ausgeschieden. Es ist nicht das robusteste System, aber kostet auch nur die Datenträger und der Zugriff darauf ist praktisch über jedes Betriebssystem möglich.

Die einzige Schwäche, die sich in den Jahren gezeigt hat, ist eben das anfangs erwähnte Problem, dass zuerst die Daten vollständig kopiert und in einem zweiten, späteren Durchgang alles getouched wird.

Deine Methode mit einer Dateiliste als Zwischenschritt, die Variablen nach Bedarf anpassen / belegen. Der Zeitstempel der Quelldatei wird sofort nach dem Kopieren geändert.

Das echo "$line" habe ich bewußt zweimal eingefügt, damit man auf der Konsole sieht, welche Datei gerade bearbeitet wird.

1
2

find "$quellordner"  -type f -newermt "$zeitstempel_alt" | tee $dateiliste 
cat "$dateiliste" | while read line;do echo "$line" && echo "$line" | cpio -pd "$zielordner" && touch -d "$zeitstempel_neu" "$line";done

Norfolk schrieb:

Ich verwende mein System seit ca. 27 Jahren im privaten Bereich, um praktisch alle Daten doppelt und offline abzulegen, nachdem ich in den Jahren auch ca. 10 HDD-Ausfälle erlebt habe. Der älteste aktive Datenträger ist 9 Jahre alt, vor Kurzem wurde einer nach 13 Jahren ausgeschieden. Es ist nicht das robusteste System, aber kostet auch nur die Datenträger und der Zugriff darauf ist praktisch über jedes Betriebssystem möglich.

Ich bin mir nicht sicher, was Du damit sagen willst.

Die einzige Schwäche, die sich in den Jahren gezeigt hat, ist eben das anfangs erwähnte Problem, dass zuerst die Daten vollständig kopiert und in einem zweiten, späteren Durchgang alles getouched wird.

Da ist mindestens noch die Schwäche, dass der Zustand aller Dateien geändert wird, um die Informationen über das Backup zu speichern. Damit geht Dir die Information über den tatsächlichen Änderungszeitpunkt verloren.

rklm schrieb:

Da ist mindestens noch die Schwäche, dass der Zustand aller Dateien geändert wird, um die Informationen über das Backup zu speichern. Damit geht Dir die Information über den tatsächlichen Änderungszeitpunkt verloren.

Ich kann Norfolk schon irgendwie verstehen. Jeder entwickelt im Laufe der Zeit so seine persönlichen Vorlieben und Methoden, dabei nimmt man halt auch gewisse Umstände / Ergebnisse in Kauf , welche andere vielleicht als völliges "das geht überhaupt nicht" einstufen. Mich würde das geänderte Dateidatum auch stören.

Wenn man bei der jetzigen Methode bleiben will, wäre es eventuell sinnvoller, sich nur das letzte Backup-Datum abzuspeichern und für den neuen Suchlauf als find-Kriterium zu verwenden.

1
2
3
4

touch letztes_backup.txt
...
letztes_backup=$(stat -c %y letztes_backup.txt | cut -d '.' -f1)
find "$quellordner"  -type f -newermt "$letztes_backup"

Wenn sich innerhalb der Laufzeit des Backups Dateien ändern sollten, dann ist die jetzige Methode natürlich nicht wirklich gut geeignet.

rklm schrieb:

Ich bin mir nicht sicher, was Du damit sagen willst.

Da ist mindestens noch die Schwäche, dass der Zustand aller Dateien geändert wird, um die Informationen über das Backup zu speichern. Damit geht Dir die Information über den tatsächlichen Änderungszeitpunkt verloren.

Ich meine damit, es ist ein einfaches System, dass lediglich Kosten für Datenträger verursacht und ohne spezielle Software auf die Daten zugegriffen werden kann. Für mich reicht es vollkommen, bis auf das erwähnte Problem.

Der tatsächliche Änderungszeitpunkt einer Datei wie z.B. "Urlaub-Berlin-2009/Bild_1.jpg" ist für mich nicht relevant, aber wenn ich z.B. ein Foto eines Berlin-Aufenthalts suche, hab ich im Verzeichniskatalog mit einem Befehl alle HDDs rausgesucht, wo mögliche Berlin-Fotos enthalten sind. PS: Ja genau, "ls -laR > HDD_15_Files" und "cat HDD* | grep -i Berlin" 😉

Ich habe durchaus Erfahrung mit den diversen Backup-Lösungen gemacht und mir ist bewusst, dass jeder Zweck seine passende Lösung hat. Mein aktuelles ist für diesen Zweck ausreichend.

Edit: Ein Flüchtigkeitsfehler, den Dateikatalog erstelle ich z.B. mit "find" statt oben "ls", damit ich die vollen Dateipfade pro Zeile "greppen" kann.

Warum kompliziert, wenn es auch einfach geht:

https://wiki.ubuntuusers.de/Skripte/Backup_mit_RSYNC/

Einfach, zuverlässig und SCHNELL. Nur meine 2cent.

Viele freundliche Grüsse, juribel

Danke für die 2cents, ich verstehe jedoch nicht, wie rsync mein Problem lösen könnte?

@Norfolk: Meinen Beitrag von gestern 23:15 Uhr hast du gelesen?

Ich habe dich so verstanden, dass du Backups auf externen Festplatten machen willst. Korrigiere mich gerne, ich bin ein Querleser (nicht -denker!!) und habe vielleicht etwas überlesen.

Die Skripte muss man ein bisschen konfigurieren, je nachdem WAS man WO gesichert haben will. Auf dem Ziel-Laufwerk wird für jeden Tag ein neuer Ordner angelegt, der augenscheinlich ALLE Dateien, die gesichert sind, umfasst. In Wirklichkeit sind es "nur" hard links und keine immer neuen Kopien. So ist in der gesamten Sicherung jede Datei, die nicht geändert wurde, nur 1x vorhanden. Nur neue oder geänderte Dateien werden "in echt" in die neue Tages-Sicherung kopiert.

Sorry, wenn ich dich falsch verstanden habe. Waren wirklich nur "2 cents" ☺

Viele freundliche Grüsse juribel

juribel: No worries. Danke jedenfalls für den Versuch!

dingsbums: Ähm, ich muss gestehen die Antwort ist mir tatsächlich entgangen. Sieht auf den 1. Blick nach der gesuchten Lösung aus, Vielen Dank - auch fürs Nachfassen, k.a. wie mir das Posting entgehen konnte.

rklm: Danke auch für den Input - hier und auch überall sonst wo ich in Deinen Postings meist als stiller Mitleser schon Hilfe gefunden habe.

LG, Norfolk