Sicherung von Image Files / raw Devices / Blocked Files

Die Möglichkeiten von Blocked Files

Große Image-Dateien, die sich nur in Teilen geändert haben, komplett zu sichern ist ineffizient: Platz und Zeit werden verschwendet. Hier einige Beispiele:

• Einige E-Mail Programme verwenden das traditionelle mbox (mailbox) Format, um E-Mails zu speichern. Das ist praktisch, weil es sich dabei um ein sehr gut unterstütztes Format handelt. Aber Du erhältst eine große Datei von eventuell mehreren Gigabyte mit allen Deinen E-Mails darin. Das zu sichern heißt alles zu sichern - trotz der Tatsache, dass sich nur ein sehr kleiner Teil darin geändert hat.
  Dieselbe Kategorie sind die .pst Dateien von Outlook. Wenn Du solche Dateien sichern musst (und sie groß sind), solltest Du darüber nachdenken, „Blocked Files`` zu verwenden.
• Wenn Du eine Image-Datei mit einem verschlüsselten Dateisystem darin verwendest, wie das z.B. TrueCrypt macht, solltest Du die verschlüsselte Datei sichern, nicht die Dateien darin. Wenn Du die Dateien darin sicherst, brauchst Du einen weiteren verschlüsselten Container, was bedeutet, dass das Backup-Programm alle Passworte benötigt, um automatisch die Sicherungen durchzuführen - was eine perfekte Sicherheitslücke ist.
  Aus diesem Grund ist es sinnvoll, das binäre Daten-Image selbst so zu sichern, wie es ist. Wenn Du eine einfache Kopie machst, wird diese jedes Mal die Größe der Image-Datei haben (Du kannst diese Daten nicht komprimieren). Dieses ist eine ideale Situation, storeBackups „Blocked Files``-Möglichkeiten (ohne Kompression) zu nutzen; womit Du viele historisierte Versionen des Images haben kannst, ohne zu viel Platz zu benötigen und ohne ein Sicherheitsloch (storeBackup braucht kein Passwort zu wissen und weiß nichts über den Inhalt, den es sichert).
• Images für Hypervisor wie Xen, DVM oder VMware sind ein anderes Beispiel für den sehr erfolgreichen Einsatz von „Blocked Files``.
• Du solltest „Blocked Files`` nicht für Dateien verwenden, die als Ganzes komprimiert sind, wie jpegs oder komprimierte oder verschlüsselte Dateien (.gz, .bze, ġpg, etc). Änderungen an einem Teil derartiger Dateien führen meist zu einer Änderung der gesamten Datei.
• Das Feature von Blocked Files ist auch nicht sinnvoll für Datenbank-Dumps, weil storeBackup (bis jetzt) mit festen Blockgrößen arbeitet. Wenn man nur ein Byte an den Beginn einer Datei hinzufügt, sind alle Blöcke unterschiedlich.

So funktioniert's

Wenn Du eine Datei für das blockweise Sichern spezifizierst (Beschreibung siehe unten), dann geht storeBackup.pl wie folgt vor:

1. Erzeugt ein Verzeichnis mit derselben Kombination von Pfad und Dateinamen wie die originale Image Datei im Quellverzeichnis.
2. Teilt die Quelldatei in Blöcke und überprüft, ob die Blöcke irgendwo anders im Backup vorkommen (siehe Option otherBackupSeries von storeBackup.pl). Wenn ein Block schon existiert, wird ein Hardlink gesetzt; wenn er nicht existiert, wird er kopiert oder komprimiert gespeichert.
3. Die md5-Summe aller dieser Dateien wird in einer speziellen Datei namens .md5BlockCheckSums.bz2 in diesem Verzeichnis gespeichert.
4. storeBackup.pl berechnet ebenfalls die md5-Summe der gesamten Datei und speichert sie in der Datei .md5CheckSum.

Weil auf schon vorhandene Dateien über Hardlinks referenziert wird, ist jedes Backup vollständig (full backup).

Wenn Du die Option lateLinks verwendest, werden die Links später erzeugt. Wenn Du die Option lateCompress verwendest, wird die Kompression ebenfalls erst später durchgeführt.

Speichern großer Image-Dateien

Es gibt zwei Arten zu konfigurieren, welche Dateien storeBackup.pl als „Blocked Files`` behandeln soll:

1. Der einfachste Weg ist, die folgenden Optionen zu verwenden:

   checkBlocksSuffix

   Die Konfiguration ist ähnlich zu exceptSuffix; eine Liste von Endungen wird auf Übereinstimmung überprüft, z.B. $\backslash$.vdmk für VMware Images. Sie bedeuten einfach nur, dass der letzte Teil des Dateinamens mit dem übereinstimmen muss, was Du hier vorgegeben hast.
   Die hier als nächstes beschriebenen Optionen werden nur ausgewertet, wenn checkBlocksSuffix gesetzt ist.

   checkBlocksMinSize

   Nur Dateien mit der hier festgelegten Minimalgröße werden als Blocked Files behandelt. Du kannst dieselben Kürzel verwenden wie in Definition von Regeln, das bedeutet z.B. 50M 50 Megabytes. Der Standardwert ist 100M.

   checkBlocksBS

   Legt die Blöckgröße fest, in die die betroffenen „Blocked Files`` von storeBackup.pl zerteilt werden. Das Format ist mit checkBlocksMinSize identisch. Der Standardwert ist 1M; der Minimalwert ist 10k.

   checkBlocksCompr

   Definiert, ob die Blöcke komprimiert werden sollen. Mögliche Werte sind yes, no oder check. Auf der Kommandozeile ist --checkBlocksCompr zu setzen.
   Dieses Flag betrifft nur die Dateien, die mit checkBlocksSuffix ausgewählt wurden.

   Beispiel:
   Du willst alle Deine VMware-Images und auch einige Outlook .pst-Dateien sichern. Das Blocked File-Feature von storeBackup soll für Dateien mit minimal 50 Megabyte für Dateien, die auf .vmdk oder .pst enden verwendet werden. Die gewählte Blockgröße ist 500k und die resultierenden Blöcke im Backup werden komprimiert:

   checkBlocksSuffix = '\.vmdk' '\.pst'
   checkBlocksMinSize = 50M
   checkBlocksBS = 500k
   checkBlocksCompr = yes
   

2. Die flexiblere Art und Weise, mit Blocked Files zu arbeiten, ist, Regeln wie in Definition von Regeln beschrieben zu verwenden. Die folgenden Optionen sind fünf Mal verfügbar, es gibt checkBlocksRule0, checkBlocksRule1, checkBlocksRule2, checkBlocksRule3 und checkBlocksRule4:

   checkBlocksRulei

   Die ite Regel zur Festlegung, welche Dateien als Blocked Files im Backup gespeichert werden sollen.

   checkBlocksBSi

   Die korrespondierende Blockgröße für die Blöcke im Backup. Der Standardwert ist 1 Megabyte; der minimal zulässige Werte 10k.

   checkBlocksCompri

   Die Blöcke werden komprimiert, wenn auf yes gesetzt. Wenn auf no gesetzt, werden sie nicht komprimiert. Wenn auf check gesetzt, schätzt storeBackup selbst ab, ob sich eine Kompression lohnen würde. Dieses kann zu einem Mix von komprimierten und kopierten Blöcken führen.

   checkBlocksReadi

   Definiert einen Filter für das Lesen der hier als „Blocked Files`` spezifizierten Dateien, z.B. gunzip oder gzip -d. Diese Option kann nützlich sein, wenn eine bereits komprimierte Datei vorliegt. (Die Verwendung des „Blocked File``-Features von storeBackup mit bereits komprimierten Dateien ist nicht sinnvoll.)

   Beispiel:
   Angenommen, Du hast ein TrueCrypt-Image auf Deiner Platte und willst jedes Mal ein Backup davon anlegen, wenn Du storeBackup.pl startest. Du wählst den unauffälligen Namen myPics.iso, Blockgröße ist 1M, keine Kompression. Dementsprechend legst Du Regel 0 fest:

   checkBlocksRule0= '$file =~ m#/myPics\.iso$#'
   #checkBlocksBS0=
   #checkBlocksCompr0=
   checkBlocksRule1= '$size > &::SIZE("50M")' and
           ( '$file =~ m#\.pst$#' or '$file =~ m#windows_D/Outlook/#' )
   checkBlocksBS1=200k
   checkBlocksCompr1=check
   

   Hier hast Du auch Regel 1 definiert, die für alle Dateien größer als 50 Megabyte, die auf .pst enden oder im relativen Pfad unterhalb von windows_D/Outlook liegen. (Ich verwende diese Konfiguration, um Daten meines dual Boot Laptops zu sichern.) Wenn Du mit dem Erstellen von Regeln nicht vertraut bist, solltest Du Kapitel 7.4 lesen..

Du kannst checkBlocksSuffix und checkBlocksRule i gleichzeitig in der Konfigurationsdatei verwenden. StoreBackup überprüft erst checkBlocksRulei (in aufsteigender Reihenfolge), danach checkBlocksSuffix.

Sichern von ganzen Devices

Das Sichern eines ganzen Devices (wie /dev/sdc oder /dev/sdc1) erfolgt mit storeBackup auf dieselbe Art und Weise wie das Sichern einer Image-Datei. Du wählst die Devices mit checkDevicesi, die Blockgröße im Backup mit checkDevicesBSi und schaltest die Komprimierung mit checkDevicesCompri an, aus, oder auf check. Zusätzlich musst Du den relativen Pfad mit checkDevicesDiri im Backup festlegen. Dort wird der Inhalt des Devices gespeichert.

Die Blöcke, die sich im Backup aus den Image-Dateien oder Devices ergeben, werden mit Hardlinks verbunden, sofern storeBackup Übereinstimmungen findet.

Die Optionen im Detail:

checkDevicesi

Liste der zu sichernden Devices (z.B. /dev/sdd2 /dev/sde1).

--checkDevicesDiri

Verzeichnis, in dem die Inhalte der Devices innerhalb des Backups gespeichert werden (relativer Pfad). Die Image-Datei wird in dieses (relative) Verzeichnis zurückgesichert, wenn Du storeBackupRecover.pl benutzt (bei Verwendung von Standard-Parametern). In diesem Verzeichnis erzeugt storeBackup ein Unterverzeichnis mit einem von den Parametern der Option checkDevices abgeleiteten Name, z.B. wird /dev/sdc zu /dev_sdc.

checkDevicesBSi

Legt die Blockgröße fest, in die die Devices von storeBackup.pl aufgeteilt werden. Das Format ist identisch mit checkBlocksMinSize. Der Standardwert ist 1M; der minimal erlaubte Werte ist 10k.

checkDevicesCompri

Legt fest, ob die Blöcke komprimiert werden sollen. Mögliche Werte sind yes, no oder check; der Standardwert ist no.
Diese Option betrifft nur Devices, die mit checkDevices i ausgewählt wurden. Wenn Du diese Option auf check setzt, wird jeder Block individuell auf Komprimierung überprüft.

Wahl der Blockgröße

Es gibt keine feste Regel für die „beste`` Blockgröße. Ich habe einige Messungen bezüglich der Blockgröße und des benötigten Platzes gemacht. Das zweite Backup wurde dabei mit lateLinks gemacht (siehe Kapitel 7.6), so dass ich mit df sehen konnte, wie viel Platz wirklich benötigt wurde. Das verwendete Dateisystem war reiserfs mit tail packing. Wenn Du ein Dateisystem ohne tail packing (wie ext2, ext3 oder ext4) verwendest, ist der Overhead größer und kleine Blockgrößen werden uninteressanter (genauso wie bei Verwendung von Komprimierung). Das Resultat hängt auch von der Applikation ab, die in die originale Image-Datei schreibt.
Alle Beispiele wurden aus Performance-Gründen ohne Kompression durchgeführt. Sie erfolgten mit echten Daten. In meinen realen Backups verwende ich natürlich die Komprimierung. Das zweite Backup zeigt den Platz, der für die Änderungen benötigt wird. Die Prozentzeile darunter zeigt die Relation zwischen dem ersten und zweiten Backup. Die Summenzeile zeigt die Summe des Platzbedarfs von erstem und zweitem Backup. Die nächste Zeile (1x) zeigt das Verhältnis des letzten Werte in der Zeile (große Blockgröße, 5M) zur aktuellen Spalte für ein Folgebackup. Die letzte Zeile zeigt dasselbe für 10 Folgebackups (es wurde angenommen, dass der Platzbedarf bei jedem zusätzlich benötigten Backup gleich ist.) Daher enthält diese Zeile die interessantesten Werte.

Das erste Beispiel zeigt das Resultat bei Sicherung einer großen Outlook .pst-Datei von 1.2GB mit den Änderungen, die ich zwischen zwei Tagen hatte:

Blockgröße	50k	100k	200k	1M	5M
1. Backup [kB]	1219253	1172263	1172863	1173801	1173724
2. Backup [kB]	7692	13445	22720	73826	240885
	0.63%	1.15%	1.94%	6.29%	20.52%
Summe [kB]	1226945	1185708	1195583	1247627	1414609
1x	86.73%	83.82%	84.52%	88.20%	100.00%
10x	36.18%	36.47%	39.08%	53.37%	100.00%

Das zweite Beispiel wurde mit einer kleineren Outlook Datei von 117 Megabyte durchgeführt. Diese dient als „Posteingang``. Die Zahlen zeigen ein anderes Verhalten als beim ersten Beispiel.

Blockgröße	50k	100k	200k	1M	5M
1. Backup [kB]	122487	118221	118891	119184	119181
2. Backup [kB]	33400	51240	74424	107632	119181
	27.27%	43.34%	62.60%	90.31%	100.00%
Summe [kB]	155887	169461	193315	226816	238362
1x	65.40%	71.09%	81.10%	95.16%	100.00%
10x	34.82%	48.10%	65.84%	91.19%	100.00%

Das dritte Beispiel zeigt das Resultat bei Speicherung einer VMware Image Datei von 2.1 GB. Zwischen dem ersten und dem zweiten Backup wurde die VM gebootet, ein Programm zum Updaten meines Navigationssystems auf einen neuen Stand gebracht und das Navigations Gerät selbst für einen Update angeschlossen.

Blockgröße	50k	100k	200k	1M	5M
1. Backup [kB]	2162595	2106781	2112547	2117178	2117094
2. Backup [kB]	53656	80609	131701	438241	1112652
	2.48%	3.83%	6.23%	20.70%	52.56%
Summe [kB]	2216251	2187390	2244248	2555419	3229746
1x	68.62%	67.73%	69.49%	79.12%	100.00%
10x	20.38%	21.99%	25.90%	49.08%	100.00%

Bei allen Tabellen sieht man, dass ab einem gewissen Punkt eine Verkleinerung der Blockgröße den benötigten Platz nicht mehr reduziert. Ein optimaler Wert scheint zwischen 50k und 200k zu liegen (sofern tail packing verwendet wird).

Es gibt einen weiteren wichtigen Aspekt bezüglich der Blockgröße: Bei kleineren Blockgrößen wird die Performance schlechter. Um eine akzeptable Performance zu erreichen, sind folgende Optimierungen implementiert:

• Wenn Du die Blöcke mit storeBackup.pl nicht komprimierst (überhaupt nicht oder erst später wegen Verwendung von lateCompress), wird keine Parallelisierung verwendet.
• Wenn die Blöcke von storeBackup.pl komprimiert werden und eine Blockgröße von 1 Megabyte oder mehr verwendet wird, parallelisiert storeBackup.pl.
• Falls die Kompression innerhalb von storeBackup.pl mit bzip2 erfolgt und eine Blockgröße kleiner 1 Megabyte konfiguriert ist, versucht storeBackup.pl das Perl-Modul IO::Compress::Bzip2 zu verwenden. Wenn es auf dem System installiert ist, wird es verwendet.

Am Besten machst Du eigene Tests, um ein Gefühl für eine sinnvolle Blockgröße für Deinen Anwendungsfall zu bekommen.