storeBackup, das unkonventionelle Backup Tool

ArticleCategory: [Choose a category, translators: do not translate this, see list below for available categories]

System Administration

AuthorImage:[Here we need a little image from you]

TranslationInfo:[Author + translation history. mailto: or http://homepage]

AboutTheAuthor:[A small biography about the author]

Abstract:[Here you write a little summary]

StoreBackup bietet sich f�r Privatpersonen an, die zwar nicht �ber ein Bandger�t, aber eine zweite Festplatte oder �ber einen weiteren Rechner verf�gen. Es bietet sich im professionellen Umfeld an, um den Anwendern einen extrem schnellen und bequemen Zugriff auf ihre Backups zu m�glichen, um Kosten f�r B�nder und um Administrationskosten einzusparen.

Als Alternative oder als Erg�nzung zu einer Datensicherung auf Band bietet sich die Speicherung auf Festplatten oder vergleichbare Medien an. Das hier vorgestellte Programm erm�glicht dieses auf sehr performante und Speicherplatz sparende Art und Weise:

Verzeichnisse werden rekursiv an eine andere Stelle kopiert (z.B. /home => /var/bkup/2003.12.13_02.04.26). Hierbei bleiben die Rechte der Dateien erhalten, so dass Anwender direkt auf das Backup zugreifen k�nnen.
Die Dateien werden auf ihren Inhalt untersucht. Es wird sichergestellt, dass der Inhalt jeder Datei nur einmal im Backup gespeichert wird, d.h. Dateien gleichen Inhalts existieren physisch nur einmal im Backup.
Gleiche Dateien werden �ber hard links miteinander verbunden und erscheinen so im Backup an denselben Stellen wie im Original
Dateien im Backup werden komprimiert, sofern dieses nicht �ber exclude-Pattern ausgeschlossen wird. Die Kompression kann auch vollst�ndig unterbunden werden.
Voneinander unabh�ngig erstellte Backupreihen (z.B. von unterschiedlichen Rechnern) k�nnen �ber hard links auf gemeinsame Dateien verweisen. Auch k�nnen mit dieser Methode konfigurierbar vollst�ndige und teilweise Backups erstellt werden - immer unter der Pr�misse, dass Dateien gleichen Inhalts nur einmal physisch im Backup vorkommen.

ArticleIllustration:[One image that will end up at the top of the article]

ArticleBody:[The main part of the article]

Warum ein neues Backup Tool?

Es gibt wahrscheinlich tausende von Backup Programmen. Warum also noch ein weiteres? Der Anlass ergab sich f�r mich aus meiner T�tigkeit als Berater. Ich war die ganze Woche unterwegs und hatte keine M�glichkeit, die Daten meines Laptops w�hrend der Woche zu Hause zu sichern. Alles, was ich zur Verf�gung hatte, war ein 250 MByte ZIP-Laufwerk an der parallelen Schnittstelle. Um ein Backup auf dem ZIP-Laufwerk zu erstellen, hatte ich daher relativ wenig Platz zur Verf�gung und musste mit einer schlechten Performance (ca. 200 KByte/s) leben. Au�erdem wollte ich einen schnellen und einfachen Zugriff auf meine Dateien - die �blichen Varianten mit full, differential und incremental Backups (z.B. mit tar oder dump) gefiel mir nicht: Zum einen ist es meist m�hsam, eine Datei in der gew�nschten Version wiederzufinden und zum anderen kann man nicht beliebig alte Sicherungen l�schen, sondern muss dieses beim Erstellen des Backups sorgf�ltig planen.

Mein Ziel war es, w�hrend der Arbeit 'mal schnell ein Backup machen zu k�nnen und die gesuchten Dateien schnell und unproblematisch wiederfinden zu k�nnen.

So entstand Ende 1999 die erste Version von storeBackup, die jedoch bei Einsatz in gr��eren Umgebungen nicht geeignet war. Sie war nicht performant genug, skalierte nicht hinreichend und war nicht in der Lage, mit unangenehmen Dateinamen (z.B. '\n' im Namen) umzugehen.

Mit den Erfahrungen dieser ersten Version habe ich dann eine neue geschrieben, die ich dann ein knappes Jahr sp�ter unter der GPL ver�ffentlicht habe. Inzwischen gibt es einen nicht mehr so kleinen Anwenderkreis, der storeBackup von der privaten Datensicherung, der Sicherung von (Mail-) Verzeichnissen bei ISPs oder Kliniken und Universit�ten bis hin zur Archivierung nutzt.

Was w�re ein ideales Backup Tool?

Das ideale Backup Tool mit minimalem Aufwand f�r die Administration und maximalen Komfort f�r den Anwender w�rde von jedem Tag eine komplette Kopie des gesamten Datenbestandes (mit den jeweiligen Zugriffsrechten) auf ein anderes Dateisystem machen. Die hierzu ben�tigten Rechner und Festplattensysteme sollten selbstverst�ndlich in einem entfernten, entsprechend gesicherten Geb�ude untergebracht sein. Der Anwender k�nnte dann z.B. �ber einen Dateisystem Browser auf diese gesicherten Daten zugreifen, um in ihnen zu suchen oder die ben�tigten Dateien direkt zur�ckzukopieren. Das Backup w�rde so zu etwas direkt und problemlos verwendbarem. Hierdurch w�rde der Umgang mit Backups - da der Umweg �ber die Administration in der Regel nicht mehr notwendig ist - zu etwas "normalem".

Das hier beschriebene Vorgehen hat leider einen kleinen Nachteil: Es ben�tigt extrem viel Plattenplatz und ist - da jeweils die gesamte Datenmenge kopiert werden muss - auch ziemlich langsam.

Wie funktioniert storeBackup?

StoreBackup versucht, das oben beschriebene "ideale Backup" zu realisieren und die beiden Problem - Plattenplatz und Performance - zu l�sen.

Features

Die erste Massnahme zur Senkung des verbrauchten Plattenplatzes ist, die Dateien - wenn sinnvoll - zu komprimieren. StoreBackup erm�glicht hierbei die Verwendung eines beliebigen Kompressionsalgorithmus, der als externes Programm vorliegen muss. Defaultm�ssig wird bzip2 verwendet.

Bei n�herer Betrachung der gespeicherten Dateien f�llt auf, dass sich von Backup zu Backup nur relativ wenige Dateien �ndern - aus diesem Grund werden schlie�lich auch inkrementelle Backups durchgef�hrt. Es f�llt aber auch auf, dass viele Dateien gleichen Inhalts innerhalb eines Backups vorkommen, weil Anwender Dateien kopieren oder z.B. mit einer Versionsverwaltung wie cvs gearbeitet wird. Auch werden Dateien oder ganze Dateib�ume vom Anwender umbenannt, die bei einem �blichen inkrementellen Backup dann (unn�tigerweise) wiederum gesichert werden. Die L�sung liegt darin, zu untersuchen, ob eine Datei gleichen Inhalts bereits (eventuell komprimiert) im Backup vorliegt und dann auf diese zu verweisen. Dieser Verweis ist �ber einen Hard Link realisiert. (Erl�uterung: Die Bl�cke einer Datei werden unter Unix �ber Inodes verwaltet. Auf einen Inode k�nnen viele verschiedene Dateinamen in unterschiedlichen Verzeichnissen verweisen. Die eigentliche Datei wird erst mit dem letzten Hard Link (= Directory Namen) gel�scht. (Hard Links k�nnen nur innerhalb eines Filesystems auf dieselbe Datei exisiteren.))
�ber den Trick mit den Hard Links, die bei bereits im Backup vorhandenen Dateien auf diese gesetzt werden, liegen dann in jedem Backup s�mtliche Dateien individuell vor, obwohl gleichartige Dateien nur einmal physisch auf der Platte gespeichert werden. Das Kopieren und Umbenennen von Dateien oder ganzen Verzeichnisb�umen kostet so im Backup nur den Platz f�r die Hard Links - also fast nichts.

Es ist aber �blicherweise so, dass nicht nur ein Rechner gesichert werden soll, sondern mehrere. Diese haben, insbesondere wenn Verzeichnisse wie /etc oder /usr gesichert werden, einen sehr hohen Anteil an identischen Dateien. Es liegt nahe, dass auch hier identische Dateien nur einmal auf der Sicherungsplatte stehen sollten. Die einfachste L�sung, dieses zu erreichen, ist, alle Verzeichnisse von dem Backup Server zu mounten und alle Rechner gemeinsam zu sichern. Doppelte Dateien werden so erkannt und �ber Hard Links verbunden. Dieses Verfahren hat allerdings den Nachteil, dass alle zu sichernden Rechner gleichzeitig f�r die gesamte Zeit des Backups zur Verf�gung stehen m�ssen. In vielen F�llen, z.B. wenn Notebooks mit storeBackup gesichert werden sollen, ist ein solches Vorgehen nicht realisierbar.
Jedoch gerade bei Notebooks ist, da �blicherweise Dateien von den Anwendern lokal kopiert werden, ein sehr hoher �berdeckungsgrad der Dateien der Anwender gegeben. F�r solche F�lle, oder wenn Server unabh�ngig voneinander gesichert werden, aber trotzdem der verf�gbare Plattenplatz �ber Hard Links optimal genutzt werden soll, kann storeBackup auch in unabh�ngige Backupreihen (d.h. unabh�ngig voneinander (von eventuell unterschiedlichen Rechnern) erstellte Backups) die Dateien �ber Hard Links miteinander verbinden.

Zum L�schen der Dateien bietet storeBackup einen Satz von unterschiedlichen Regeln an. Der gro�e Vorteil beim L�schen ist, dass jedes Backup ein Full Backup ist - es k�nnen also beliebige Backups gel�scht werden. Es gibt keine Notwendigkeit - wie bei traditionellen Backups - zu ber�cksichtigen, dass ein inkrementelles Backup nur dann verwendbar ist, wenn die Vorg�nger noch verf�gbar sind.
Die Regeln erlauben das L�schen bzw. Erhalten von Sicherungen nach dem Wochentag, ersten oder letzten Tagen in der Woche / im Monat oder im Jahr. Auch kann sichergestellt werden, dass eine minimale Anzahl von Sicherungen behalten wird. Dieses ist insbesondere dann sinnvoll, wenn Backups nicht regelm��ig durchgef�hrt werden. So k�nnen z.B. nach einem 4-w�chigem Urlaub die letzten n Backups des Laptops erhalten werden, obwohl das Erhalten von Backups nur auf drei Wochen eingestellt war. Es ist weiterhin m�glich, eine maximale Anzahl von Backups anzugeben. Hier existieren weitere M�glichkeiten um Konflikte bei divergierenden Regeln (sinnvoll) zu l�sen.

Performance

Das oben beschriebene Verfahren geht davon aus, dass �berpr�ft wird, ob zu einer zu sichernden Datei bereits eine gleichen Inhalts im Backup vorliegt. Dieses betrifft sowohl Dateien in der alten Sicherung, als auch im gerade angelegten neuen Backup. Es macht nat�rlich keinen Sinn, jede zu sichernde Datei mit jeder bereits gesicherten zu vergleichen. Daher werden von den gesicherten Dateien die md5 Summen vorgehalten, mit denen die md5 Summe der zu sichernden Datei unter Verwendung einer Hash-Tabelle verglichen wird. Das Programm verwendet hierzu dbm Files.
Das Berechnen der md5 Summe geht zwar schnell, dauert aber bei gr��eren Datenmengen auch lange. Aus diesem Grund �berpr�ft storeBackup zuerst, ob die Datei seit der letzten Sicherung unver�ndert ist (Pfad + Dateiname, ctime, mtime und size gleich). Wenn ja, wird einfach die md5 Summe der letzten Sicherung �bernommen und der Hard Link gesetzt. Wenn nicht, wird die md5 Summe berechnet und anschlie�end �berpr�ft, ob es bereits eine Datei mit derselben md5 Summe existiert. (Beim Abgleich mit mehreren Backup-Serien ist das Verfahren etwas erweitert, aber �hnlich performant.) Durch diese Vorgehensweise m�ssen f�r ein Backup in der Regel nur sehr wenige md5 Summen berechnet werden.

Mein Server (200 MHz, IDE) schafft etwas 20-35 files/sec, meine Desktop Maschine (800 MHz, IDE) etwa 150-200 files/sec. Mit einem schnellen Rechner und schnellen Platten (2.4 GHz, 1.4 TB Software RAID 5) habe ich bereits bis zu 800 files/sec gemessen. Diese Werte gelten, wenn auf die lokale Platte geschrieben wird. Beim Schreiben �ber NFS sind die Werte niedriger. Ausschlaggebend ist insbesondere die Geschwindigkeit der Festplatten. (Alle Tests wurden mit Linux durchgef�hrt.)

Realisierung

Die storeBackup Tools sind bisher auf den Betriebssystemen Linux, FreeBSD, Solaris und AIX getestet worden. Sie sollten aber auf allen Unix-Plattformen laufen. Als Programmiersprache wird perl verwendet.

Installation

Die Installation ist einfach. StoreBackup kann von www.sourceforge.net/projects/storebackup als storeBackup-version.tar.bz2 heruntergeladen werden. Anschlie�end kann es an einer gew�nschten Stelle ausgepackt werden:

tar jxf storeBackup-version.tar.bz2

Hierbei wird das Verzeichnis storeBackup erzeugt. In ihm sind die Dokumentation und im Unterverzeichnis bin die ausf�hrbaren Programme. Sie k�nnen mit vollst�ndigem Pfad aufgerufen werden. Alternativ kann auch die $PATH Environmentvariable gesetzt werden. Auf Betriebssystemen, die das Programm md5sum nicht mitliefern (z.B. FreeBSD) muss dieses noch kompiliert werden. Eine Anleitung hierzu steht in der mitgelieferten README Datei.

Bedienung

Hier sollen nicht alle M�glichkeiten im Detail beschrieben werden; sie sind im Softwarepaket beschrieben.

Die einfachste Art, eine Sicherung zu erzeugen ist:

storeBackup.pl -s sourceDir -t targetDir

Hierbei m�ssen sourceDir und targetDir existieren. StoreBackup wird die Dateien von sourceDir nach targetDir/datum_uhrzeit kopieren, dabei die Dateien, nicht auf .gz, .bz2, .png etc. enden, mit bzip2 komprimieren und doppelt vorkommende Dateien verlinken.

Das Sicherungsprogramm storeBackup.pl verf�gt in der aktuellen Version (1.14.1) �ber 45 Parameter, die zu beschreiben hier den Rahmen sprengen w�rde. Sie sind mittels

storeBackup.pl -h

abrufbar. In den Dateien README und EXAMPLES finden sich umfangreiche Erl�uterungen �ber die unterschiedlichen Anwendungsm�glichkeiten. Hier soll nur darauf hingewiesen werden, dass alternativ zu den Parametern in der Kommandozeile, die schnell un�bersichtlich werden k�nnen, auch eine Konfigurationsdatei verwendet werden kann. Diese kann mit

storeBackup.pl --generate --file ConfigFile

oder k�rzer mit

storeBackup.pl -g -f ConfigFile

generiert werden. Wenn die Konfiguration beendet ist, kann dieses mittels

storeBackup.pl -f ConfigFile --print

gelesen, auf Syntax �berpr�ft und bereits teilweise ausgewertet werden. Anschlie�end kann storeBackup mittels

storeBackup.pl -f ConfigFile

gestartet werden. Die vollst�ndige Beschreibung zu allen Optionen von storeBackp befindet sich in den Dateien README und EXAMPLES, die im tar File enthalten sind.

Um festzustellen, wo welche Version einer gesicherten Datei im Backup existiert, kann storeBackupVersion verwendet werden:

storeBackupVersion.pl -f Filename

Filename ist dabei der Dateiname der interessierenden Datei, und zwar so, wie er im Backup steht, d.h. eventuell mit Kompressionsendung. Am einfachsten geht man in das Backup-Verzeichnis an die betreffende Stelle und ruft das Kommando auf. Mit der Option "-h" wird eine Erl�uterung �ber alle 11 Parameter ausgegeben.

Das Zur�ckspielen von einzelnen Dateien wird in der Regel mittels cp, ftp, File Browser oder �hnliche Mechanismen erfolgen. Wenn jedoch Teilb�ume oder ganze Backups zur�ckgesichert werden sollen, ist es sinnvoll, das zugeh�rige Tool storeBackupRecover.pl zu verwenden. Es extrahiert die gw�nschten Dateien oder Verzeichnisse aus dem Backup. Hierbei wird der Originalzustand wiederhergestellt, d.h. User, Gruppe und die Rechte werden zur�ckgesetzt. Die Dateien werden ebenfalls entkomprimiert, sofern sie es im Originalzustand waren. Auch werden hard links, die im Original bestanden, wiederhergestellt.
Weitere Optionen von storeBackupRecover erlauben statistische Ausgaben, die Beeinflussung von Performanceparametern, das �berschreibverhalten und anderes. Die insgesamt 10 Parameter k�nnen mit Hilfe der Option '-h' ausgegeben werden.

Mittels storeBackupDel.pl k�nnen Backups unabh�ngig vom Programm storeBackup.pl gel�scht werden. Dieses kann n�tzlich sein, wenn �ber NFS gesichert wird. Das L�schen gro�er Verzeichnisb�ume �ber NFS ist wesentlich langsamger als lokal. In einem solchen Fall kann storeBackup ohne L�schfunktion �ber NFS aufgerufen werden, was auch die Backupdauer kalkulierbarer macht. Das L�schen von alten Backups auf dem Server kann dann mittels storeBackupDel - welches �ber dieselben M�glichkeiten zum L�schen wie storeBackup verf�gt - vom eigentlichen Backup entkoppelt erfolgen.

Bereits erstellte Backups sind in Verzeichnissen organisiert. Diese k�nnen mit storeBackupls.pl (verst�ndlicher als mittels 'ls') angezeigt werden. Entweder als einfache Liste

hjc@schlappix:~/backup ) storeBackupls.pl /media/zip/stbu/
  1  Fri May 23 2003   2003.05.23_12.37.53   -156
  2  Fri Jun 06 2003   2003.06.06_14.31.47   -142
  3  Fri Jun 13 2003   2003.06.13_14.17.18   -135
  4  Fri Jun 20 2003   2003.06.20_14.02.35   -128
  5  Fri Jun 27 2003   2003.06.27_14.23.55   -121
  6  Mon Jun 30 2003   2003.06.30_17.34.37   -118
  7  Fri Jul 04 2003   2003.07.04_13.10.06   -114
  8  Fri Jul 11 2003   2003.07.11_13.13.14   -107
  9  Fri Jul 18 2003   2003.07.18_14.03.49   -100
 10  Fri Jul 25 2003   2003.07.25_14.19.19   -93
 11  Thu Jul 31 2003   2003.07.31_17.07.55   -87
 12  Fri Aug 01 2003   2003.08.01_12.16.58   -86
 13  Fri Aug 15 2003   2003.08.15_15.10.19   -72
 14  Sat Aug 23 2003   2003.08.23_06.25.35   -64
 15  Wed Aug 27 2003   2003.08.27_18.21.09   -60
 16  Thu Aug 28 2003   2003.08.28_14.16.39   -59
 17  Fri Aug 29 2003   2003.08.29_14.35.10   -58
 18  Mon Sep 01 2003   2003.09.01_17.19.56   -55
 19  Tue Sep 02 2003   2003.09.02_18.18.46   -54
 20  Wed Sep 03 2003   2003.09.03_16.22.41   -53
 21  Thu Sep 04 2003   2003.09.04_16.59.19   -52
 22  Fri Sep 05 2003   2003.09.05_14.35.20   -51
 23  Mon Sep 08 2003   2003.09.08_20.08.52   -48
 24  Tue Sep 09 2003   2003.09.09_18.45.48   -47
 25  Wed Sep 10 2003   2003.09.10_18.30.48   -46
 26  Thu Sep 11 2003   2003.09.11_17.26.46   -45
 27  Fri Sep 12 2003   2003.09.12_15.23.03   -44
 28  Mon Sep 15 2003   2003.09.15_18.05.19   -41
 29  Tue Sep 16 2003   2003.09.16_18.04.16   -40
 30  Wed Sep 17 2003   2003.09.17_19.03.02   -39
 31  Thu Sep 18 2003   2003.09.18_18.21.09   -38
 32  Fri Sep 19 2003   2003.09.19_14.48.05   -37  not finished
 33  Mon Sep 22 2003   2003.09.22_18.58.55   -34
 34  Tue Sep 23 2003   2003.09.23_18.48.40   -33
 35  Wed Sep 24 2003   2003.09.24_19.32.24   -32
 36  Thu Sep 25 2003   2003.09.25_18.05.38   -31
 37  Fri Sep 26 2003   2003.09.26_14.59.59   -30
 38  Mon Sep 29 2003   2003.09.29_18.42.59   -27
 39  Tue Sep 30 2003   2003.09.30_18.02.03   -26
 40  Wed Oct 01 2003   2003.10.01_17.09.43   -25
 41  Thu Oct 02 2003   2003.10.02_15.26.33   -24
 42  Mon Oct 06 2003   2003.10.06_20.08.45   -20
 43  Tue Oct 07 2003   2003.10.07_19.46.54   -19
 44  Wed Oct 08 2003   2003.10.08_16.03.23   -18
 45  Thu Oct 09 2003   2003.10.09_16.58.28   -17
 46  Fri Oct 10 2003   2003.10.10_14.21.06   -16
 47  Mon Oct 13 2003   2003.10.13_18.58.24   -13
 48  Tue Oct 14 2003   2003.10.14_16.02.44   -12
 49  Wed Oct 15 2003   2003.10.15_19.04.12   -11
 50  Thu Oct 16 2003   2003.10.16_15.47.51   -10
 51  Mon Oct 20 2003   2003.10.20_09.34.52   -6
 52  Mon Oct 20 2003   2003.10.20_12.16.40   -6
 53  Tue Oct 21 2003   2003.10.21_09.43.40   -5
 54  Tue Oct 21 2003   2003.10.21_11.22.36   -5
 55  Tue Oct 21 2003   2003.10.21_16.01.15   -5
 56  Tue Oct 21 2003   2003.10.21_18.08.07   -5
 57  Wed Oct 22 2003   2003.10.22_10.02.51   -4
 58  Wed Oct 22 2003   2003.10.22_16.09.42   -4
 59  Wed Oct 22 2003   2003.10.22_18.03.05   -4
 60  Thu Oct 23 2003   2003.10.23_08.18.15   -3
 61  Thu Oct 23 2003   2003.10.23_14.16.24   -3
 62  Thu Oct 23 2003   2003.10.23_17.00.36   -3
 63  Fri Oct 24 2003   2003.10.24_13.29.30   -2
 64  Sun Oct 26 2003   2003.10.26_09.08.55   0

(Das 'not finished' zeigt hier an, dass das entsprechende Backup abgebrochen wurde.)
oder mit den Informationen zum in der Konfigurationsdatei angegebenen L�schverhalten:

hjc@schlappix:~/backup ) storeBackupls.pl -f stbu.conf /media/zip/stbu/
analyse of old Backups in </media/zip/stbu/>:
 Fri 2003.05.23_12.37.53 (156): keepLastOfMonth(400d)
 Fri 2003.06.06_14.31.47 (142): keepLastOfWeek(150d)
 Fri 2003.06.13_14.17.18 (135): keepLastOfWeek(150d)
 Fri 2003.06.20_14.02.35 (128): keepLastOfWeek(150d)
 Fri 2003.06.27_14.23.55 (121): keepLastOfWeek(150d)
 Mon 2003.06.30_17.34.37 (118): keepLastOfMonth(400d)
 Fri 2003.07.04_13.10.06 (114): keepLastOfWeek(150d), keepMinNumber50
 Fri 2003.07.11_13.13.14 (107): keepLastOfWeek(150d), keepMinNumber49
 Fri 2003.07.18_14.03.49 (100): keepLastOfWeek(150d), keepMinNumber48
 Fri 2003.07.25_14.19.19 (93): keepLastOfWeek(150d), keepMinNumber47
 Thu 2003.07.31_17.07.55 (87): keepLastOfMonth(400d), keepMinNumber46
 Fri 2003.08.01_12.16.58 (86): keepLastOfWeek(150d), keepMinNumber45
 Fri 2003.08.15_15.10.19 (72): keepLastOfWeek(150d), keepMinNumber44
 Sat 2003.08.23_06.25.35 (64): keepLastOfWeek(150d), keepMinNumber43
 Wed 2003.08.27_18.21.09 (60): keepMinNumber42, keepWeekDays(60d)
 Thu 2003.08.28_14.16.39 (59): keepMinNumber41, keepWeekDays(60d)
 Fri 2003.08.29_14.35.10 (58): keepLastOfMonth(400d), keepLastOfWeek(150d), 
                               keepMinNumber40, keepWeekDays(60d)
 Mon 2003.09.01_17.19.56 (55): keepMinNumber39, keepWeekDays(60d)
 Tue 2003.09.02_18.18.46 (54): keepMinNumber38, keepWeekDays(60d)
 Wed 2003.09.03_16.22.41 (53): keepMinNumber37, keepWeekDays(60d)
 Thu 2003.09.04_16.59.19 (52): keepMinNumber36, keepWeekDays(60d)
 Fri 2003.09.05_14.35.20 (51): keepLastOfWeek(150d), keepMinNumber35, keepWeekDays(60d)
 Mon 2003.09.08_20.08.52 (48): keepMinNumber34, keepWeekDays(60d)
 Tue 2003.09.09_18.45.48 (47): keepMinNumber33, keepWeekDays(60d)
 Wed 2003.09.10_18.30.48 (46): keepMinNumber32, keepWeekDays(60d)
 Thu 2003.09.11_17.26.46 (45): keepMinNumber31, keepWeekDays(60d)
 Fri 2003.09.12_15.23.03 (44): keepLastOfWeek(150d), keepMinNumber30, keepWeekDays(60d)
 Mon 2003.09.15_18.05.19 (41): keepMinNumber29, keepWeekDays(60d)
 Tue 2003.09.16_18.04.16 (40): keepMinNumber28, keepWeekDays(60d)
 Wed 2003.09.17_19.03.02 (39): keepMinNumber27, keepWeekDays(60d)
 Thu 2003.09.18_18.21.09 (38): keepMinNumber26, keepWeekDays(60d)
 Fri 2003.09.19_14.48.05 (37): keepLastOfWeek(150d), keepMinNumber25, keepWeekDays(60d)
 Mon 2003.09.22_18.58.55 (34): keepMinNumber24, keepWeekDays(60d)
 Tue 2003.09.23_18.48.40 (33): keepMinNumber23, keepWeekDays(60d)
 Wed 2003.09.24_19.32.24 (32): keepMinNumber22, keepWeekDays(60d)
 Thu 2003.09.25_18.05.38 (31): keepMinNumber21, keepWeekDays(60d)
 Fri 2003.09.26_14.59.59 (30): keepLastOfWeek(150d), keepMinNumber20, keepWeekDays(60d)
 Mon 2003.09.29_18.42.59 (27): keepMinNumber19, keepWeekDays(60d)
 Tue 2003.09.30_18.02.03 (26): keepLastOfMonth(400d), keepMinNumber18, keepWeekDays(60d)
 Wed 2003.10.01_17.09.43 (25): keepMinNumber17, keepWeekDays(60d)
 Thu 2003.10.02_15.26.33 (24): keepLastOfWeek(150d), keepMinNumber16, keepWeekDays(60d)
 Mon 2003.10.06_20.08.45 (20): keepMinNumber15, keepWeekDays(60d)
 Tue 2003.10.07_19.46.54 (19): keepMinNumber14, keepWeekDays(60d)
 Wed 2003.10.08_16.03.23 (18): keepMinNumber13, keepWeekDays(60d)
 Thu 2003.10.09_16.58.28 (17): keepMinNumber12, keepWeekDays(60d)
 Fri 2003.10.10_14.21.06 (16): keepLastOfWeek(150d), keepMinNumber11, keepWeekDays(60d)
 Mon 2003.10.13_18.58.24 (13): keepMinNumber10, keepWeekDays(60d)
 Tue 2003.10.14_16.02.44 (12): keepMinNumber9, keepWeekDays(60d)
 Wed 2003.10.15_19.04.12 (11): keepMinNumber8, keepWeekDays(60d)
 Thu 2003.10.16_15.47.51 (10): keepLastOfWeek(150d), keepMinNumber7, keepWeekDays(60d)
 Mon 2003.10.20_09.34.52 (6): keepDuplicate(7d)
 Mon 2003.10.20_12.16.40 (6): keepMinNumber6, keepWeekDays(60d)
 Tue 2003.10.21_09.43.40 (5): keepDuplicate(7d)
 Tue 2003.10.21_11.22.36 (5): keepDuplicate(7d)
 Tue 2003.10.21_16.01.15 (5): keepDuplicate(7d)
 Tue 2003.10.21_18.08.07 (5): keepMinNumber5, keepWeekDays(60d)
 Wed 2003.10.22_10.02.51 (4): keepDuplicate(7d)
 Wed 2003.10.22_16.09.42 (4): keepDuplicate(7d)
 Wed 2003.10.22_18.03.05 (4): keepMinNumber4, keepWeekDays(60d)
 Thu 2003.10.23_08.18.15 (3): keepDuplicate(7d)
 Thu 2003.10.23_14.16.24 (3): keepDuplicate(7d)
 Thu 2003.10.23_17.00.36 (3): keepMinNumber3, keepWeekDays(60d)
 Fri 2003.10.24_13.29.30 (2): keepLastOfWeek(150d), keepMinNumber2, keepWeekDays(60d)
 Sun 2003.10.26_09.08.55 (0): keepLastOfMonth(400d), keepLastOfWeek(150d), 
                              keepMinNumber1, keepWeekDays(60d)

Zus�tzlich zu den oben beschriebenen Programmen f�r das Backup sind noch die Programme llt und multtail enthalten. llt zeigt creating, modifiy und access time von Dateien an. Mittels multitail k�nnen mehrere Dateien gleichzeitig wie mit 'tail -f' verfolgt werden. Multitail bietet aber mehr M�glichkeiten als 'tail -f' und ist wesentlich robuster.

Weitere Pl�ne

F�r die n�chsten Versionen von storeBackup sind folgende Features geplant:

Die Hauptzeit beim Erstellen eines Backups wird (au�er beim ersten Backup, in dem alles komprimiert / kopiert wird) f�r die Erzeugung der hard links verbraucht. Das Erzeugen eines hard links ist zwar sehr schnell, durch die relativ zu den anderen Operationen gro�e Anzahl - und die Parallelisierung insbesondere der Kompression - liegt hier jedoch der haupts�chliche Zeitverbrauch.
Die n�chste Version von storeBackup wird die M�glichkeit er�ffnen, im ersten Schritt nur die Directory-Struktur und die ver�nderten Dateien in der Sicherung zu erzeugen. Danach ist das Backup aus Sicht des zu sichernden Mediums abgeschlossen. In einem zweiten Schritt werden dann die noch fehlenden hard links erzeugt. Diese beiden Schritte werden vollst�ndig entkoppelt sein - d.h. sie k�nnen auf unterschiedlichen Rechnern laufen und es wird m�glich sein, mehrere Backups zu fahren, bevor die neuen hard links erzeugt werden.
Nach ersten Messungen wird diese Option einen Performancegewinn gegen�ber der "normalen" Komplettsicherung um einen Faktor von 5-10 ergeben, wenn lokal geschrieben wird. Bei einer Sicherung auf einen �ber NFS gemounteten Rechner wird er deutlich h�her ausfallen.
F�r die darauffolgende Version ist geplant, die M�glichkeiten zum Suchen (mit anschlie�ender R�cksicherung) zu erweitern. Es soll m�glich sein, in den Sicherungen mit einer beliebigen Regel aus Dateinamen (Pattern), Dateigr��e, Erstellungs- / Ver�nderungszeit, User ID, Group ID, Rechten auf der Datei und einem (einfachen) grep auf den Inhalt suchen zu k�nnen. Diese Regeln beinhalten dann 'and', 'or', 'not' und beliebige Klammerungen.
Anschlie�end sehen die k�nftigen Pl�ne eine Erweiterung der Optionen (in Anlehnung an tar) und die Unterst�tzung von bisher nicht sicherbaren Dateitypen, wie z.B. Devices vor.

Version und Lizenz

Die zum Zeitpunkt der Erstellung dieses Artikels aktuelle Version des storeBackup Paketes ist 1.14.1. Sie kann, wie schon oben erw�hnt, unter http://www.sourceforge.net/projects/storebackup heruntergeladen werden.
StoreBackup steht unter der GPL.