Inkrementelle Sicherungen mit tar, bei denen die aktuelle und letzte Dateien der aktuellen Datei vorhanden sind, haben nur unterschiedliche Versionen

500
IMTheNachoMan

Ich bin ein wenig damit vertraut, wie man mit tardem --listed-incrementalFlag inkrementelle Backups erstellt. Das Endergebnis ist eine backup-0Datei, die die ersten vollständigen Back-up hat und dann backup-1, backup-2, ..., backup-xmit den Änderungen in der Reihenfolge der Backups.

In der Vergangenheit habe ich rsyncHard-Links verwendet, um Backups zu erstellen, wobei der backup-0aktuelle Status und jeder backup-xOrdner die Dateien enthält, die für dieses Backup spezifisch waren. Grundsätzlich was http://www.mikerubel.org/computers/rsync_snapshots/ und http://www.admin-magazine.com/Articles/Using-rsync-for-Backups/(offset) beschrieben wird .

Ich möchte diese Funktionalität mit Teer nachahmen. Ich kann keine Hard-Links verwenden, da die TAR-Dateien letztendlich zu einem Cloud-Anbieter hochgeladen werden, der keine Links aufrechterhält / versteht und was nicht. Ich möchte auch die Backups tarieren, da ich sie auch verschlüsseln kann, bevor sie in die Cloud hochgeladen werden.

Die Idee ist also, eine wachsende Liste von Dateien zu haben, wie zB:

  • backup-0.tar.bz2 - Dies ist das aktuelle Backup und wird das größte sein, da es sich um ein vollständiges Backup handelt
  • backup-1.tar.bz2- Dies ist die Sicherung von gestern, aber es werden nur die Dateien vorhanden sein, die sich von den Dateien in current ( backup-0.tar.bz2) unterscheiden.
  • backup-2.tar.bz2- Dies ist das Backup von vor zwei Tagen, aber es werden nur die Dateien vorhanden sein, die sich von gestern unterscheiden ( backup-1.tar.bz2).
  • backup-3.tar.bz2 - ...
  • backup-4.tar.bz2 - ...
  • backup-5.tar.bz2 - ...

Wenn das hoffentlich keinen Sinn ergibt, wird dies der Fall sein.

Erstes Mal:

  1. $ touch /tmp/file1
  2. $ touch /tmp/file2
  3. machen backup-0.tar.bz2

An diesem Punkt backup-0.tar.bz2hat /tmp/file1und /tmp/file2.

Zweites Mal:

  1. $ touch /tmp/file3
  2. $ rm /tmp/file2
  3. ..mag die Magie

An diesem Punkt:

  • backup-0.tar.bz2hat /tmp/file1und/tmp/file3
  • backup-1.tar.bz2hat /tmp/file2; Es hat keine file1Ursache, es hat sich nicht verändert, also ist es inbackup-0.tar.bz2

Drittes Mal:

  1. $ touch /tmp/file1
  2. $ touch /tmp/file4
  3. ..mag die Magie

An diesem Punkt:

  • backup-0.tar.bz2hat /tmp/file1, /tmp/file3und/tmp/file4
  • backup-1.tar.bz2hat, /tmp/file1weil es geändert wurde
  • backup-2.tar.bz2 hat /tmp/file2

So wie:

| | first time | second time | third time | |-------|------------|-------------|-------------------------| | file1 | backup-0 | backup-0 | backup-0 and backup-1 | | file2 | backup-0 | backup-1 | backup-2 | | file3 | | backup-0 | backup-0 | | file4 | | | backup-0 |

Ich dachte mir, dass dies ein Weg ist, um mich dem zu nähern, aber es erscheint mir furchtbar ineffizient. Vielleicht gibt es Funktionen / Flags, die ich verwenden kann, um dies effizienter zu gestalten.

  1. erstes mal = nehmen backup-0
  2. zweites Mal
    1. Umbenennen backup-0inbackup-1
    2. nehmen backup-0
    3. entfernen Sie alles von backup-1diesen Übereinstimmungenbackup-0
  3. drittes Mal
    1. Umbenennen backup-1inbackup-2
    2. Umbenennen backup-0inbackup-1
    3. nehmen backup-0
    4. entfernen Sie alles von backup-1diesen Übereinstimmungenbackup-0
  4. viertes Mal
    1. Umbenennen backup-2inbackup-3
    2. Umbenennen backup-1inbackup-2
    3. Umbenennen backup-0inbackup-1
    4. nehmen backup-0
    5. entfernen Sie alles von backup-1diesen Übereinstimmungenbackup-0

Ich glaube, dass es der letzte Schritt ist (alles aus backup-1den Übereinstimmungen entfernen backup-0), der ineffizient ist.

Meine Frage ist, wie kann ich das machen? Wenn ich's verwende tar, --listed-incrementalwürde ich genau das tun, was ich versuche.

1
Wie macht man das. Wenn ich `tar '' --listed-incremental 'verwende, wird das genau das Gegenteil von dem sein, was ich versuche. IMTheNachoMan vor 5 Jahren 0

1 Antwort auf die Frage

0
Kamil Maciorowski

Wenn ich's verwende tar, --listed-incrementalwürde ich genau das tun, was ich versuche.

Es ist gut, dass Sie das erkennen. Ich kann Vor- und Nachteile beider Richtungen sehen (ich werde sie hier nicht besprechen). Technisch ist es möglich, den Prozess umzukehren:

  1. Umbenennen backup-Nin backup-(N+1)Schleife von N max bis 0.
  2. Stellen Sie die vollständige Sicherung (jetzt backup-1) in einem temporären Verzeichnis wieder her.
  3. Erstellen Sie backup-0aus den aktuellen Daten eine neue Snapshot-Datei.
  4. Entfernen Sie backup-1(vorherige vollständige Sicherung).
  5. Behandle das temporäre Verzeichnis als "neue" Version. Erstellen Sie backup-1als inkrementelle Sicherung, indem Sie die Momentaufnahmedatei aus dem vorherigen Schritt bereitstellen. (Beachten Sie, dass Sie Ihr Arbeitsverzeichnis von den aktuellen Daten in die temporären ändern müssen, damit die relativen Pfade gleich bleiben.)

Sie fragen sich vielleicht, ob die alten (aufbewahrten) backup-NDateien dadurch mit den neuen Dateien in Einklang gebracht werden. Ein berechtigter Zweifel, da das Handbuch sagt:

-g, --listed-incremental=FILE
Behandeln Sie neue inkrementelle Backups im GNU-Format. FILEist der Name einer Momentaufnahmedatei, in der tarzusätzliche Informationen gespeichert werden, anhand derer entschieden wird, welche Dateien sich seit dem vorherigen inkrementellen Speicherauszug geändert haben und folglich erneut gesichert werden müssen. Wenn FILEbeim Erstellen eines Archivs nicht vorhanden ist, wird es erstellt und alle Dateien werden zum resultierenden Archiv hinzugefügt (Level- 0Dump). Um inkrementelle Archive mit einem anderen Level als Null zu Nerstellen, erstellen Sie eine Kopie der Snapshot-Datei, die während des Levels erstellt wurde N-1, und verwenden Sie sie als FILE.

Daher wird vorgeschlagen, dass die Momentaufnahmedatei vollständig von der vollständigen Sicherung aus aktualisiert wird, als ob Sie die backup-NDateien jedes Mal neu erstellen müssen, wenn Sie eine vollständige Sicherung durchführen. Aber dann:

Beim Auflisten oder Extrahieren wird der tatsächliche Inhalt FILEnicht geprüft, er wird nur aufgrund syntaktischer Anforderungen benötigt. Es ist daher üblich, an /dev/nullseiner Stelle zu verwenden.

Das heißt, wenn Sie backup-NDateien in aufsteigender Reihenfolge extrahieren, um vor einiger Zeit einen Status zu erhalten, backup-Merwartet jede Datei (M> 0) nur einen gültigen M-1Status. Es ist egal, ob dieser Status von einer vollständigen oder inkrementellen Sicherung abgerufen wird. Der Status sollte jedoch ohnehin identisch sein. So sollte es keine Rolle, ob Sie die erstellte backup-MDatei auf der Grundlage einer vollständigen Sicherung (wie Sie tun, jeder backup-Mbeginnt, backup-1wo backup-0eine vollständige Sicherung) oder basierend auf einer Kette von inkrementellen Sicherungen (wie das Handbuch schon sagt).

Ich verstehe Ihren Standpunkt zu halten backup-0als up-to-date und vollständige Sicherung der Lage sein, „gehen Sie zurück in der Zeit“ mit backup-0, backup-1, backup-2, ... Wenn Sie diese Dateien in einem „dummen“ Cloud - Service halten wollen, werden Sie Sie müssen sie entsprechend dem Verfahren sorgfältig umbenennen, ersetzen backup-1und backup-0jedes Mal ein neues hochladen . Wenn Ihre Daten riesig sind, wird das Hochladen eines vollständigen Backups jedes Mal sehr schmerzhaft.

Aus diesem Grund ist es ratsam, einen "intelligenten" Server zu haben, der die aktuelle vollständige Sicherung jedes Mal erstellt, wenn Sie eine inkrementelle Sicherung "von früher bis heute" hochladen. Ich habe rdiff-backupeinige Male benutzt:

rdiff-backupSichert ein Verzeichnis in einem anderen, möglicherweise über ein Netzwerk. Das Zielverzeichnis erstellt eine Kopie des Quellverzeichnisses. Zusätzliche umgekehrte Diffs werden jedoch in einem speziellen Unterverzeichnis dieses Zielverzeichnisses gespeichert. Sie können also Dateien wiederherstellen, die vor einiger Zeit verloren gegangen sind. Die Idee ist, die besten Funktionen eines Spiegels und eine inkrementelle Sicherung zu kombinieren. rdiff-backupBewahrt auch Unterverzeichnisse, feste Links, Dev-Dateien, Berechtigungen, UID / GID-Besitz, Änderungszeiten, erweiterte Attribute, ACLs und Ressourcen-Gabeln. Ebenso rdiff-backupkann über eine Leitung, wie z rsync. B. bandbreiteneffizient gearbeitet werden .

Bitte beachten Sie, dass die Software seit 2009 nicht mehr aktualisiert wurde. Ich weiß nicht, ob dies heutzutage eine gute Empfehlung ist.

Vielen Dank. Dies könnte funktionieren, aber es würde viel Speicherplatz erfordern, um das vollständige Verzeichnis in das temporäre Verzeichnis zu extrahieren. Ich habe eine Idee zu tun, was ich will und arbeite an einem Skript. 1) Inventar der zu sichernden Dateien einschließlich Mod-Zeit und Größe sichern 2) Archivdateien, einschließlich Inventardateien später 1) Inventardatei aus dem Archiv extrahieren 2) neue Inventardatei nehmen 3) zwei Dateien vergleichen 4) verschiedene Dateien extrahieren und neue Dateien einfügen Archiv. IMTheNachoMan vor 5 Jahren 0

Verwandte Probleme