next up previous contents
Nächste Seite: Verwendung der Option lateLinks Aufwärts: Grundlegende Konzepte Vorherige Seite: Festlegen, ob eine Datei   Inhalt


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:

So funktioniert's

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

\includegraphics[scale=.9]{blockedFile}
  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:

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


next up previous contents
Nächste Seite: Verwendung der Option lateLinks Aufwärts: Grundlegende Konzepte Vorherige Seite: Festlegen, ob eine Datei   Inhalt
Heinz-Josef Claes 2014-04-20