Dateien als Ganzes speichern
Die erste Methode, den benötigten Plattenplatz zu sparen, besteht darin, die Daten zu komprimieren - falls das sinnvoll ist. StoreBackup erlaubt es, jeden Komprimierungsalgorithmus als externes Programm zu verwenden. Standard ist bzip2.
Wenn man sich Backups näher ansieht, fällt auf, dass sich von Sicherung zu Sicherung relativ wenige Dateien ändern - was der Grund für inkrementelle Backups ist. Man stellt auch fest, dass viele Dateien denselben Inhalt haben, weil die Nutzer (untereinander) Dateien kopieren oder eine Versionsverwaltung (wie cvs) verwendet wird. Zusätzlich werden Dateien oder ganze Verzeichnisbäume von den Anwendern umbenannt, was in inkrementellen Backups zu wiederholten (unnötigen) Sicherungen führt. Die Lösung hierfür ist, im Backup nach Dateien zu suchen, die schon denselben Inhalt haben (möglicherweise sind diese schon komprimiert) und dann auf diese zu verweisen. Mit dem Trick, hierfür Hardlinks auf bereits bestehende Dateien im Backup zu verwenden, ist jede Datei in jedem Backup präsent und steht doch nur einmal auf physisch der Platte. Kopien oder Umbenennungen benötigen nur den Platz eines Hardlinks im Backup, also fast nichts.
Oft muss nicht nur ein Rechner gesichert werden, sondern eine kleinere oder größere Anzahl. Diese haben oft einen nennenswerten Anteil an identischen Dateien, insbesondere in Verzeichnissen wie /etc, /usr oder /home. Offensichtlich sollte nur eine Kopie von identischen Dateien auf dem Backup Laufwerk liegen. Alle Verzeichnisse vom Backup-Server gleichzeitig zu mounten und zu sichern wäre die einfachste Lösung. Auf diese Art würden doppelte Dateien erkannt und mittels Hardlink verknüpft. Dieser Ansatz hat aber den Nachteil, dass alle Rechner während der gesamten Sicherungszeit für das Backup verfügbar sein müssten. Das wird in vielen Fällen nicht möglich sein, wenn z.B. ein Notebook gesichert werden soll. Aber gerade bei Notebooks wird man viele Dubletten finden, weil die Anwender lokale Kopien erzeugen. Aufgrund dieser Fälle, oder wenn Server unabhängig voneinander zu sichern sind, unterstützt storeBackup für die optimale Plattenplatznutzung das Verlinken von unabhängigen Backups. (Das heißt, völlig entkoppelt und möglicherweise von unterschiedlichen Rechnern.)
Dateien aufspalten: blocked files
Die Methodik von Komprimierung und Hardlinks von ganzen Dateien
funktioniert sehr gut für „normale`` Office-, Konfigurations-,
Programmcode- und alle anderen Typen von kleinen
Dateien.
Sie schlägt bei großen Image-Dateien, bei denen sich nur Teile der
Dateien ändern, mehr oder weniger fehl. So hat eine Datei mit z.B. 3 GB
nur ein paar Megabyte Änderungen, aber die oben beschriebene
Methodik würde immer die ganze Datei ins Backup kopieren oder
komprimieren, was weder aus Sicht der Sicherungszeit noch der des
benötigten Platzes effizient ist. Um dieses Problem zu lösen, kann
storeBackup derartige Dateien gesondert verwalten.
Man kann in der Konfigurationsdatei einstellen, welche Dateien als
„blocked files`` behandelt werden sollen. Für diese Dateien wird im
Backup anstelle einer Datei ein Ordner angelegt (der Name des Ordners
ist dabei identisch mit dem Namen der betreffenden Datei). Diese
Datei wird nicht als Ganzes im Backup gespeichert; stattdessen wird
sie in Form von kleinen, nummerierten Dateien (Blöcken) im dafür
erzeugten Ordner angelegt. Diese Blöcke können
auch komprimiert werden.
Im nächsten Backup (nachdem in der Originaldatei etwas verändert
wurde) überprüft storeBackup, in welchem dieser Blöcke ein Änderung
erfolgte und kopiert / komprimiert nur diese Blöcke (erzeugt
also nur diese Dateien). Die, die sich nicht geändert haben, werden
per Hardlink verknüpft. Dieser auf md5-Summen basierende Vergleich
erfolgt auch mit anderen „blocked files``, so dass z.B. bei einer
VM, die für unterschiedliche Verwendungszwecke dupliziert wurde, die
doppelten Blöcke von storeBackup erkannt werden. Dies gilt auch für
mehrfach vorkommende Blöcke innerhalb einer Image-Datei (z.B.
wenn unbenutzte Teile in diesen Dateien genullt sind und in größerem Umfang bei
sogenannten sparse
Dateien8).
Das Resultat aus diesem Vorgehen ist ein dramatisch reduzierter
Platzbedarf, verglichen mit dem Kopieren / Komprimieren der vollständigen
Dateien, und es ist immer noch möglich, die Dateien auch ohne ein
lauffähiges storeBackup zurückzusichern, was die Philosophie von
storeBackup ist. (Zurücksichern ist die wichtigste Funktion eines
Backups.) Dies könnte in z.B. 10 Jahren sehr nützlich sein - wer
weiß, was dann ist (gibt's storeBackup noch, unterschiedliche Perl
Versionen, ...)
Löschen von Backups
StoreBackup bietet für das Löschen von Sicherungen vielfältige
Optionen. Der große Vorteil ist hier, dass jede Sicherung ein
vollständiges Backup ist und daher aufgrund nichtexistenter
Abhängigkeiten der Backups untereinander beliebig gelöscht werden
kann. Im Gegensatz zu „traditionellen`` Backups gibt es keine
Notwendigkeit zu berücksichtigen, ob ein inkrementelles Backup
vom vorherigen „Vollbackup`` abhängt.
Die Optionen ermöglichen das Löschen oder Erhalten von Backups an
bestimmten Wochentagen oder des ersten oder letzten existierenden Backups
einer Woche, eines Monats oder eines Jahres. Auch kann eine Minimalanzahl
von Backups angegeben werden, die erhalten werden soll. Dies ist
insbesondere dann sinnvoll, wenn die Backups nicht regelmäßig erstellt
werden. So können die letzten Backups eines Laptops nach einem
4-wöchigen Urlaub selbst dann erhalten werden, wenn die
Aufbewahrungsfrist nur drei Wochen ist. Sich widersprechende Regeln werden
dabei von storeBackup „mit gesundem Menschenverstand`` aufgelöst.