Late Links Backups

Nächste Seite: Replikation Aufwärts: Interna Vorherige Seite: Vollständige Backups Inhalt

Late Links Backups

Ein Backup mit der Option lateLinks durchzuführen bedeutet, dass die Erstellung des Backups in zwei Teile getrennt wird. Der erste Teil läuft mit storeBackup.pl, welches alle Dateien mit neuem Inhalt erkennt und kopiert - der zweite Teil erfolgt mit storeBackupUpdateBackup.pl, welches:

symblock-Links erzeugt und Dateien komprimiert (falls Option lateCompress gewählt war),
Hardlinks setzt, sowie
Datei- und Verzeichnisrechte setzt.

Der wichtigste Teil - bezogen auf die Struktur von storeBackup - ist das Erzeugen der (noch fehlenden) Hardlinks im Backup. Das bewirkt, dass aus dem noch nicht vollständigen Backup, welches eine Art inkrementelle Sicherung ist,⁶⁰ ein vollständiges Backup wird.

Erstellen wir ein Beispiel:

$ mkdir /tmp/a
$ cd /tmp/a
$ mkdir -p s/sub1 b
$ cp /bin/ls /bin/pwd s
$ cp /bin/ls /bin/pwd s/sub1

Wähle ein anderes Verzeichnis Deiner Wahl, falls das Directory /tmp/a auf Deinem Rechner schon existiert. Wir haben jetzt ein sourceDir s mit ein wenig Inhalt sowie ein backupDir b erzeugt.

Jetzt läuft das erste Backup mit Option --lateLinks und -lateCompress. Sieh auf das Resultat:

$ storeBackup.pl -s s -b b --lateLinks --lateCompress
.....
$ find b -print | sort
b
b/default
b/default/2013.08.10_10.14.00
b/default/2013.08.10_10.14.00/ls
b/default/2013.08.10_10.14.00/.md5CheckSums.bz2
b/default/2013.08.10_10.14.00/.md5CheckSums.info
b/default/2013.08.10_10.14.00/pwd
b/default/2013.08.10_10.14.00/.storeBackupLinks
b/default/2013.08.10_10.14.00/.storeBackupLinks/linkFile.bz2

Du siehst:

der gewählte Serienname ist default
die zwei Metadaten Dateien .md5CheckSums.bz2 und .md5CheckSums.info wurden erzeugt
die Dateien ls ind pwd sind im Backup, allerdings nicht komprimiert; weiterhin fehlen die Dateien sub1/ls und sub1/pwd
in .storeBackupLinks gibt es die Datei linkFile.bz2

Dieses „link file``beinhaltet die Information, was noch zu tun ist:

$ bzcat b/default/2013.08.10_10.14.00/.storeBackupLinks/linkFile.bz2
# link md5sum
#	existingFile
#	newLink
# compress md5sum
#	fileToCompress
# dir dirName
# symlink file
#	target
# linkSymlink link
#	existingFile
#	newLink
dir sub1
compress c5f89e40c144b6fb8b61f2ef72e4b556
pwd
compress b5607b4dc7d896c0fab5c4a308239161
ls
link c5f89e40c144b6fb8b61f2ef72e4b556
./pwd.bz2
sub1/pwd.bz2
link b5607b4dc7d896c0fab5c4a308239161
./ls.bz2
sub1/ls.bz2

In den ersten auskommentierten Zeilen wird die Syntax kurz erklärt. Du siehst, dass folgendes ausgeführt werden soll (alle Pfade sind relativ zum aktuellen Backup Verzeichnis):

erzeuge Directory sub1
komprimiere Datei pwd (sie wird dann pwd.bz2)
komprimiere Datei ls (sie wird dann ls.bz2)
Hard linke sub1/pwd.bz2 nach pwd.bz2
Hard linke sub1/ls.bz2 nach ls.bz2

Es gibt keine Abhängigkeiten zu anderen Verzeichnisse, weil dieses das erste Backup war.

Nach dem lauf von storeBackupUpdateBackup.pl ergibt sich:

$ storeBackupUpdateBackup.pl -b b
.....
$ find b -ls 
232815    0 drwxrwxr-x   3 hjc  hjc    60 Aug 10 10:14 b
240109    0 drwx------   3 hjc  hjc    60 Aug 10 12:18 b/default
305119    0 drwxr-xr-x   4 hjc  hjc   160 Aug 10 12:15 b/default/2013.08.10_11.52.15
249568   52 -rwxr-xr-x   2 hjc  hjc 49915 Aug 10 10:03 b/default/2013.08.10_11.52.15/ls.bz2
249567   16 -rwxr-xr-x   2 hjc  hjc 13395 Aug 10 10:03 b/default/2013.08.10_11.52.15/pwd.bz2
323964    0 drwxrwxr-x   2 hjc  hjc    80 Aug 10 10:03 b/default/2013.08.10_11.52.15/sub1
249568   52 -rwxr-xr-x   2 hjc  hjc 49915 Aug 10 10:03 b/default/2013.08.10_11.52.15/sub1/ls.bz2
249567   16 -rwxr-xr-x   2 hjc  hjc 13395 Aug 10 10:03 b/default/2013.08.10_11.52.15/sub1/pwd.bz2
306983    4 -rw-rw-r--   1 hjc  hjc   300 Aug 10 11:52 b/default/2013.08.10_11.52.15/.md5CheckSums.bz2
305122    4 -rw-------   1 hjc  hjc   950 Aug 10 11:52 b/default/2013.08.10_11.52.15/.md5CheckSums.info
305120    0 drwx------   2 hjc  hjc    40 Aug 10 12:15 b/default/2013.08.10_11.52.15/.storeBackupLinks

Du siehst, dass ls und pwd komprimiert wurden. Die Hardlinks vom Subdirectory sub1 wurden ebenfalls erstellt. Letztendlich wurden die Berechtigungen korrigiert und .storeBackupLinks/linkFile.bz2 existiert nicht mehr. Dieses Backup ist nun vervollständigt.

Lassen wir storeBackup.pl ein zweites Mal laufen:

$ storeBackup.pl -s s -b b --lateLinks --lateCompress
.....
$ find b -print | sort
b
b/default
b/default/2013.08.10_10.14.00
b/default/2013.08.10_10.14.00/ls.bz2
b/default/2013.08.10_10.14.00/.md5CheckSums.bz2
b/default/2013.08.10_10.14.00/.md5CheckSums.info
b/default/2013.08.10_10.14.00/pwd.bz2
b/default/2013.08.10_10.14.00/.storeBackupLinks
b/default/2013.08.10_10.14.00/.storeBackupLinks/linkFrom0
b/default/2013.08.10_10.14.00/sub1
b/default/2013.08.10_10.14.00/sub1/ls.bz2
b/default/2013.08.10_10.14.00/sub1/pwd.bz2
b/default/2013.08.10_11.52.15
b/default/2013.08.10_11.52.15/.md5CheckSums.bz2
b/default/2013.08.10_11.52.15/.md5CheckSums.info
b/default/2013.08.10_11.52.15/.storeBackupLinks
b/default/2013.08.10_11.52.15/.storeBackupLinks/linkFile.bz2
b/default/2013.08.10_11.52.15/.storeBackupLinks/linkTo

Du siehst nun eine Änderung im ersten Backup: Es existiert jetzt die Datei .storeBackupLinks/linkFrom0. Diese Datei hat folgenden Inhalt:

$ cat b/default/2013.08.10_10.14.00/.storeBackupLinks/linkFrom0
../2013.08.10_11.52.15

Das bedeutet, dass mindestens eine noch zu setzende Referenz mit dem relativen Pfad 2013.08.10_11.52.15 zu diesem Backup exisitert. Wenn Referenzen von mehreren anderen Backups existierten, würde es mehrere Dateien dieser Art (linkFrom1, linkFrom2, ...), die diese Abhängigkeiten beschreiben, geben. Aufgrund dieser Datei oder Dateien erkennt storeBackupDel.pl, dass derartige Backups nicht gelöscht werden dürfen, da sonst die Informationen, auf die spätere Backups (über nicht-ausgeführte Links) verweisen, verloren gehen würden.

In dem neuen Backup (2013.08.10_11.52.15) listet die Datei .storeBackupLinks/linkTo sämtliche anderen Sicherungen auf, zu denen dieses Backup Referenzen hat (in diesem Fall nur eine).

$ cat b/default/2013.08.10_11.52.15/.storeBackupLinks/linkTo
../2013.08.10_10.14.00

Wie Du an der Auflistung der Dateien im zweiten Backup sehen kannst, gibt es in diesem neuen Backup keine Dateien mit Daten aus dem sourceDir - es gibt nur Meta Daten von storeBackup. Das ist richtig, denn seit dem ersten Backup haben sich keine Dateien im Quellverzeichnis verändert. Sehen wir ins linkFile:

$ bzcat b/default/2013.08.10_11.52.15/.storeBackupLinks/linkFile.bz2
# link md5sum
#	existingFile
#	newLink
# compress md5sum
#	fileToCompress
# dir dirName
# symlink file
#	target
# linkSymlink link
#	existingFile
#	newLink
link c5f89e40c144b6fb8b61f2ef72e4b556
../2013.08.10_10.14.00/sub1/pwd.bz2
pwd.bz2
link b5607b4dc7d896c0fab5c4a308239161
../2013.08.10_10.14.00/sub1/ls.bz2
ls.bz2
dir sub1
link c5f89e40c144b6fb8b61f2ef72e4b556
../2013.08.10_10.14.00/sub1/pwd.bz2
sub1/pwd.bz2
link b5607b4dc7d896c0fab5c4a308239161
../2013.08.10_10.14.00/sub1/ls.bz2
sub1/ls.bz2

Es ist leicht zu erkennen, dass alle fehlenden Dateien per Hardlink erzeugt sowie das Unterverzeichnis erstellt werden sollen.

Unten sieht man die Änderungen nach einem Lauf von storeBackupUpdateBackup.pl:

$ storeBackupUpdateBackup.pl -b b
.....
$ find b -ls 
232815    0 drwxrwxr-x   3 hjc  hjc    60 Aug 10 10:14 b
240109    0 drwx------   4 hjc  hjc    80 Aug 10 11:52 b/default
305119    0 drwxr-xr-x   4 hjc  hjc   160 Aug 10 12:15 b/default/2013.08.10_11.52.15
249568   52 -rwxr-xr-x   4 hjc  hjc 49915 Aug 10 10:03 b/default/2013.08.10_11.52.15/ls.bz2
249567   16 -rwxr-xr-x   4 hjc  hjc 13395 Aug 10 10:03 b/default/2013.08.10_11.52.15/pwd.bz2
323964    0 drwxrwxr-x   2 hjc  hjc    80 Aug 10 10:03 b/default/2013.08.10_11.52.15/sub1
249568   52 -rwxr-xr-x   4 hjc  hjc 49915 Aug 10 10:03 b/default/2013.08.10_11.52.15/sub1/ls.bz2
249567   16 -rwxr-xr-x   4 hjc  hjc 13395 Aug 10 10:03 b/default/2013.08.10_11.52.15/sub1/pwd.bz2
306983    4 -rw-rw-r--   1 hjc  hjc   300 Aug 10 11:52 b/default/2013.08.10_11.52.15/.md5CheckSums.bz2
305122    4 -rw-------   1 hjc  hjc   950 Aug 10 11:52 b/default/2013.08.10_11.52.15/.md5CheckSums.info
305120    0 drwx------   2 hjc  hjc    40 Aug 10 12:15 b/default/2013.08.10_11.52.15/.storeBackupLinks
241222    0 drwxr-xr-x   4 hjc  hjc   160 Aug 10 10:27 b/default/2013.08.10_10.14.00
249568   52 -rwxr-xr-x   4 hjc  hjc 49915 Aug 10 10:03 b/default/2013.08.10_10.14.00/ls.bz2
249567   16 -rwxr-xr-x   4 hjc  hjc 13395 Aug 10 10:03 b/default/2013.08.10_10.14.00/pwd.bz2
249566    0 drwxrwxr-x   2 hjc  hjc    80 Aug 10 10:03 b/default/2013.08.10_10.14.00/sub1
249568   52 -rwxr-xr-x   4 hjc  hjc 49915 Aug 10 10:03 b/default/2013.08.10_10.14.00/sub1/ls.bz2
249567   16 -rwxr-xr-x   4 hjc  hjc 13395 Aug 10 10:03 b/default/2013.08.10_10.14.00/sub1/pwd.bz2
238098    4 -rw-rw-r--   1 hjc  hjc   300 Aug 10 10:14 b/default/2013.08.10_10.14.00/.md5CheckSums.bz2
241225    4 -rw-------   1 hjc  hjc   950 Aug 10 10:14 b/default/2013.08.10_10.14.00/.md5CheckSums.info
241223    0 drwx------   2 hjc  hjc    40 Aug 10 12:15 b/default/2013.08.10_10.14.00/.storeBackupLinks

Wie Du siehst, ist das Ergebnis ein vollständiges Backup.

Das war bis jetzt alles das normale Verhalten - nichts lief falsch. Ich erzeuge nun ein neues backupDir (b1) und lasse es schiefgehen:

$ storeBackup.pl -s s -b b1
.....
$ storeBackup.pl -s s -b b1 --lateLinks --lateCompress
.....
$ find b1 -print | sort
b1
b1/default
b1/default/2013.08.10_13.47.41
b1/default/2013.08.10_13.47.41/ls.bz2
b1/default/2013.08.10_13.47.41/.md5CheckSums.bz2
b1/default/2013.08.10_13.47.41/.md5CheckSums.info
b1/default/2013.08.10_13.47.41/pwd.bz2
b1/default/2013.08.10_13.47.41/.storeBackupLinks
b1/default/2013.08.10_13.47.41/.storeBackupLinks/linkFrom0
b1/default/2013.08.10_13.47.41/sub1
b1/default/2013.08.10_13.47.41/sub1/ls.bz2
b1/default/2013.08.10_13.47.41/sub1/pwd.bz2
b1/default/2013.08.10_13.49.21
b1/default/2013.08.10_13.49.21/.md5CheckSums.bz2
b1/default/2013.08.10_13.49.21/.md5CheckSums.info
b1/default/2013.08.10_13.49.21/.storeBackupLinks
b1/default/2013.08.10_13.49.21/.storeBackupLinks/linkFile.bz2
b1/default/2013.08.10_13.49.21/.storeBackupLinks/linkTo

Du erkennst jetzt ein vollständiges Backup (das erste) und ein zweites, nicht-vollständiges Backup.

Aus irgendeinem Grund wird das zweite Backup gelöscht. Vielleicht wurde während der Sicherung (nehmen wir an, sie dauerte sehr lange) bemerkt, dass eine Option falsche war und das Backup wurde mit control-c (Steuerung-c) abgebrochen. Anschließend wurde das unfertige Backup einfach gelöscht. In diesem Beispiel lösche ich nun das zweite Backup:

$ rm -r b1/default/2013.08.10_13.49.21

Allerdings existiert die Datei b1/default/2013.08.10_13.47.41/.storeBackupLinks/linkFrom noch, so dass die Backup-Serie nicht konsistent ist.
Die Ausführung von storeBackupUpdateBackup.pl erzeugt eine Fehlermeldung:

$ storeBackupUpdateBackup.pl -b b1
BEGIN     2013.08.10 13:57:46   475 checking references and backup copying in <b1>
VERSION   2013.08.10 13:57:46   475 storeBackupUpdateBackup.pl, 3.4 +
INFO      2013.08.10 13:57:46   475 creating lock file </tmp/storeBackup.lock>
INFO      2013.08.10 13:57:46   475 scanning directory <b1> for existing backups
INFO      2013.08.10 13:57:46   475 scanning directory <b1/default> for existing backups
STATISTIC 2013.08.10 13:57:46   475 found 1 backup series, 1 backups, 0 renamed backups
ERROR     2013.08.10 13:57:46   475 link <../2013.08.10_13.49.21> to non existing dir in
                                    </tmp/a/b1/default/2013.08.10_13.47.41/.storeBackupLinks/linkFrom0>
ERROR     2013.08.10 13:57:46   475 found 1 inconsistencies, please repair and check again

Die Datei zu löschen, könnte eine schlechte Idee sein, weil in einer realen Umgebung vermutlich noch andere Referenzen zu diesem Backup zeigen würden. Was bedeutet, dass die Anpassung nicht so einfach wäre, die Aktion falsch wäre und die Situation leicht noch schlechter machen würde.

Wir haben mit storeBackupUpdateBackup.pl zwei Möglichkeiten:

Option --autorepair überprüft das Backup und erzeugt die fehlenden Referenzen oder Löscht die, die ins Nichts zeigen.
Option --interactive fragt immer, was gemacht werden soll, wenn eine Inkonsistenz gefunden wird.

Weil die Option --autorepair nicht destruktiv ist, ist sie in 99% der Fälle eine gute Wahl. Aus diesem Grund verwende ich jetzt --autorepair:

$ storeBackupUpdateBackup.pl -b b1 --autorepair
BEGIN     2013.08.10 17:06:59  4569 checking references and backup copying in <b1>
VERSION   2013.08.10 17:06:59  4569 storeBackupUpdateBackup.pl, 3.4 +
INFO      2013.08.10 17:06:59  4569 removing old lock file of process <475>
INFO      2013.08.10 17:06:59  4569 creating lock file </tmp/storeBackup.lock>
INFO      2013.08.10 17:06:59  4569 scanning directory <b1> for existing backups
INFO      2013.08.10 17:06:59  4569 scanning directory <b1/default> for existing backups
STATISTIC 2013.08.10 17:06:59  4569 found 1 backup series, 1 backups, 0 renamed backups
ERROR     2013.08.10 17:06:59  4569 link <../2013.08.10_13.49.21> to non existing dir in 
                                    </tmp/a/b1/default/2013.08.10_13.47.41/.storeBackupLinks/linkFrom0>
INFO      2013.08.10 17:06:59  4569 autorepair: deleted
                                    </tmp/a/b1/default/2013.08.10_13.47.41/.storeBackupLinks/linkFrom0>
ERROR     2013.08.10 17:06:59  4569 ----- repeating consistency check -----
INFO      2013.08.10 17:06:59  4569 scanning directory <b1> for existing backups
INFO      2013.08.10 17:06:59  4569 scanning directory <b1/default> for existing backups
STATISTIC 2013.08.10 17:06:59  4569 found 1 backup series, 1 backups, 0 renamed backups
INFO      2013.08.10 17:06:59  4569 consistency check finished successfully
INFO      2013.08.10 17:06:59  4569 found no references to backups from lateLinks that need
                                    storeBackupUpdateBackup run
INFO      2013.08.10 17:06:59  4569 everything is updated, nothing to do
STATISTIC 2013.08.10 17:06:59  4569                       duration = 1s
STATISTIC 2013.08.10 17:06:59  4569  [sec] |      user|    system
STATISTIC 2013.08.10 17:06:59  4569 -------+----------+----------
STATISTIC 2013.08.10 17:06:59  4569 process|      0.08|      0.00
STATISTIC 2013.08.10 17:06:59  4569 childs |      0.05|      0.00
STATISTIC 2013.08.10 17:06:59  4569 -------+----------+----------
STATISTIC 2013.08.10 17:06:59  4569 sum    |      0.13|      0.00 => 0.13
INFO      2013.08.10 17:06:59  4569 syncing ...
END       2013.08.10 17:06:59  4569 checking references and copying in <b1>
$ find b1 -print | sort
b1
b1/default
b1/default/2013.08.10_13.47.41
b1/default/2013.08.10_13.47.41/ls.bz2
b1/default/2013.08.10_13.47.41/.md5CheckSums.bz2
b1/default/2013.08.10_13.47.41/.md5CheckSums.info
b1/default/2013.08.10_13.47.41/pwd.bz2
b1/default/2013.08.10_13.47.41/.storeBackupLinks
b1/default/2013.08.10_13.47.41/sub1
b1/default/2013.08.10_13.47.41/sub1/ls.bz2
b1/default/2013.08.10_13.47.41/sub1/pwd.bz2

Die Ausgabe des find Kommandos oben zeigt, dass alles in Ordnung ist - es gibt eine vollständige Sicherung.

Nun erzeugen wir nochmals ein zweites Backup mit lateLinks:

$ storeBackup.pl -s s -b b1 --lateLinks --lateCompress
-----
$ find b1 -print | sort
b1
b1/default
b1/default/2013.08.10_13.47.41
b1/default/2013.08.10_13.47.41/ls.bz2
b1/default/2013.08.10_13.47.41/.md5CheckSums.bz2
b1/default/2013.08.10_13.47.41/.md5CheckSums.info
b1/default/2013.08.10_13.47.41/pwd.bz2
b1/default/2013.08.10_13.47.41/.storeBackupLinks
b1/default/2013.08.10_13.47.41/.storeBackupLinks/linkFrom0
b1/default/2013.08.10_13.47.41/sub1
b1/default/2013.08.10_13.47.41/sub1/ls.bz2
b1/default/2013.08.10_13.47.41/sub1/pwd.bz2
b1/default/2013.08.10_17.17.53
b1/default/2013.08.10_17.17.53/.md5CheckSums.bz2
b1/default/2013.08.10_17.17.53/.md5CheckSums.info
b1/default/2013.08.10_17.17.53/.storeBackupLinks
b1/default/2013.08.10_17.17.53/.storeBackupLinks/linkFile.bz2
b1/default/2013.08.10_17.17.53/.storeBackupLinks/linkTo

Diese Mal lösche ich das erste Backup:

$ rm -r b1/default/2013.08.10_13.47.41

Hieraus ergibt sich, dass ich nur ein nicht-vollständiges Backup habe (welches mit lateLinks erstellt wurde), dass ins Nichts verweist. Ich versuche wiederum --storeBackupUpdateBackup.pl mit Option --autorepair zu verwenden:

$ storeBackupUpdateBackup.pl -b b1 --autorepair
BEGIN     2013.08.10 17:21:08  5019 checking references and backup copying in <b1>
VERSION   2013.08.10 17:21:08  5019 storeBackupUpdateBackup.pl, 3.4 +
INFO      2013.08.10 17:21:08  5019 creating lock file </tmp/storeBackup.lock>
INFO      2013.08.10 17:21:08  5019 scanning directory <b1> for existing backups
INFO      2013.08.10 17:21:08  5019 scanning directory <b1/default> for existing backups
STATISTIC 2013.08.10 17:21:08  5019 found 1 backup series, 1 backups, 0 renamed backups
ERROR     2013.08.10 17:21:08  5019 FATAL ERROR: link <../2013.08.10_13.47.41> to non existing dir in
                                    </tmp/a/b1/default/2013.08.10_17.17.53/.storeBackupLinks/linkTo>
ERROR     2013.08.10 17:21:08  5019 found 1 inconsistencies, please repair and check again

Jetzt erhalte ich einen FATAL ERROR. Es gibt für storeBackupUpdateBackup.pl keine Chance, diesen Fehler zu reparieren. Die einzige Möglichkeit wäre, das fehlende (erste) Backup von woanders (z.B. von einer Kopie oder Replikation) an die richtige Stelle zu kopieren⁶¹ und anschließend storeBackupUpdateBackup.pl mit --autorepair laufen zu lassen. Wenn es keine andere Sicherung des fehlenden Backups gibt, sind alle Backups (und alle darauffolgenden Backups), die von diesem abhängen, nicht mehr komplettierbar. Du solltest sie löschen oder diese unvollständigen Backups an eine Stelle außerhalb von backupDir verschieben, damit sie den Ablauf (Workflow) der storeBackup-Programme nicht behindern.

Nächste Seite: Replikation Aufwärts: Interna Vorherige Seite: Vollständige Backups Inhalt

Heinz-Josef Claes 2014-04-20