Deduplizierung: Speicherplatz statt Redundanz

Standard-Inkremental-Backup

Das herkömmliche Inkremental-Backup ist bereits eine einfache Form von Deduplizierung auf Dateiebene. Denn nur, wenn sich eine Datei gegenüber dem Voll-Backup geändert hat, würde die Datei erneut gesichert werden. Würde sich daher bei einer 2 GByte großen Datei auch nur ein Byte ändern, würde die ganze Datei erneut gesichert werden, was zu Lasten des Backup-Systems geht.

Setzt man hier mit DeDup an und vergleicht die beiden sich veränderten Dateien, so würde man optimiert die zweite sich veränderte Datei als Datenbankeintrag in der Form „Dateiname von System1; Datenblöcke von Datei1; Ersetze Byte an Position 1045 durch 12“ hinterlegen. Zwar benötigt auch dieser DB-Eintrag einen gewissen Platz, aber eben nicht erneut 2 GByte.

Dieses Vorgehen könnte nun beliebig oft wiederholt werden. Hier dienen der Systemname und der Dateiname als Basis, um Dateien mit gleichem Namen miteinander zu vergleichen. Eine Wiederherstellung einer Datei würde den DB-Eintrag auswerten und die Daten beziehungsweise den Datenstrom neu zusammensetzen und dann an den Backup-Client liefern.

Es stellt sich natürlich die Frage, warum man erst zahlreich redundante Daten an den Backup-Server liefern sollte, nur damit dieser dann feststellt, dass bereits redundante Daten davon vorliegen – dies belastet das Backup-Netzwerk. Idealerweise setzt man daher bereits auf der Client-Seite an, was selbsterklärend jedoch auch wieder zu Netzwerkverkehr führt.