Vollsicherung, inkrementelle, differenzielle und synthetische Vollsicherung im Vergleich
Eine Vollsicherung kopiert alles; eine inkrementelle Sicherung kopiert, was sich seit der letzten Sicherung beliebiger Art geändert hat; eine differenzielle Sicherung (auch differentiell) kopiert, was sich seit der letzten Vollsicherung geändert hat. Forever-Incremental nimmt eine Vollsicherung und danach nur Inkremente, und eine synthetische Vollsicherung baut aus Daten, die schon im Repository liegen, eine neue Vollsicherung, ohne die Quelle erneut zu lesen. Deduplizierung arbeitet neben allen diesen Arten, indem sie identische Daten nur einmal speichert; deshalb können viele moderne Werkzeuge jeden Sicherungsstand als vollständig zeigen und doch nur speichern, was sich geändert hat.
Von Lucas Flores, IT Systeme Flores UG. Zuletzt aktualisiert am
Welche Backup-Arten gibt es, und wie schneiden sie ab?
Die Arten unterscheiden sich in vier Dingen, die später zählen: wie viel Speicher sie brauchen, wie lange ein Lauf dauert, wie viel Arbeit ein Restore macht und was ein gerissenes Glied der Kette Sie kostet.
| Art | Was kopiert wird | Speicherbedarf | Sicherungsdauer | Restore-Aufwand | Kettenrisiko |
|---|---|---|---|---|---|
| Vollsicherung | Alles Ausgewählte, jedes Mal | Am höchsten: eine vollständige Kopie je Sicherungsstand | Am längsten | Am einfachsten: ein Sicherungsstand | Keines: Jeder Sicherungsstand steht für sich |
| Inkrementell | Was sich seit der vorherigen Sicherung beliebiger Art geändert hat | Am niedrigsten je Lauf | Am kürzesten | Die letzte Vollsicherung plus jedes Inkrement seither | Am höchsten: Ein beschädigtes oder fehlendes Glied bricht jeden Sicherungsstand danach |
| Differenziell | Was sich seit der letzten Vollsicherung geändert hat | Wächst mit jedem Lauf bis zur nächsten Vollsicherung | Dazwischen, und wachsend | Die letzte Vollsicherung plus die neueste differenzielle | Mittel: Es hängt von der Vollsicherung und einer differenziellen ab; differenzielle Sicherungen hängen nicht voneinander ab |
| Forever-Incremental | Eine Vollsicherung, danach nur Inkremente; alte Stände werden für die Aufbewahrung zusammengeführt oder entfernt | Insgesamt am niedrigsten | Kurz, aber das Zusammenführen belastet das Repository zusätzlich | Folgt der Kette von der Vollsicherung durch jedes Inkrement | Hoch und dauerhaft: Die Kette schließt sich nie |
| Synthetische Vollsicherung | Eine neue Vollsicherung, aus Daten zusammengesetzt, die schon im Repository liegen | Eine Vollsicherung mehr je Zeitraum | Keine Last auf der Quelle, viel I/O auf dem Repository | Wie eine Vollsicherung: Restore aus einem Stand | Niedrig: Jede synthetische Vollsicherung schließt eine Kette, ist aber nur so gut wie die Daten, aus denen sie gebaut wurde |
| Deduplizierter Speicher | Jeder verschiedene Chunk einmal; ein Sicherungsstand listet die Chunks, die er braucht | Etwa die eindeutigen Daten über alle Sicherungsstände | Hängt davon ab, wie viel sich geändert hat | Jeder Sicherungsstand lässt sich für sich wiederherstellen | Verlagert, nicht beseitigt: Sicherungsstände teilen Chunks, ein beschädigter Chunk kann also jeden betreffen, der ihn nutzt |
Eine herstellerneutrale Zusammenfassung auf Grundlage der Dokumentation von Veeam und Microsoft und der Hinweise des BSI, die unter Quellen stehen. Einzelne Werkzeuge unterscheiden sich, lesen Sie also nach, wie Ihres seine Sicherungsstände ablegt.
Wie funktionieren Backup-Ketten?
Der Unterschied zwischen inkrementell und differenziell zeigt sich am deutlichsten daran, was ein Restore braucht. Das dritte Inkrement wiederherzustellen braucht die Vollsicherung und alle drei Inkremente in Reihenfolge. Die dritte differenzielle Sicherung wiederherzustellen braucht die Vollsicherung und diese eine differenzielle, weil jede differenzielle Sicherung an der Vollsicherung gemessen wird. Das BSI beschreibt es so: Bei der inkrementellen Sicherung müssen unter Umständen mehrere Datensicherungen nacheinander eingelesen werden, bei der differenziellen reichen die letzte Vollsicherung und die aktuellste differenzielle, dafür braucht sie mehr Speicherplatz.
Was ein Restore braucht: inkrementell und differenziell
F ist die Vollsicherung, I sind Inkremente, D sind differenzielle Sicherungen. Hervorgehobene Teile werden für das Restore der letzten gebraucht.
Schematisch. Echte Werkzeuge fügen Metadaten hinzu und können Teile der Kette zusammenführen oder neu aufbauen.
Was ist Forever-Incremental, und was ist eine synthetische Vollsicherung?
Die Methode Forever Forward Incremental von Veeam hält eine Vollsicherungsdatei und eine Reihe von Inkrementdateien. Überschreitet ein Lauf die Aufbewahrungseinstellung, wird das älteste Inkrement in die Vollsicherung eingearbeitet, die Kette braucht also nie eine neue Vollsicherung. Das spart am meisten Platz. Die Abwägungen sind das Zusammenführen, das das Repository belastet und mit der Menge der Änderungen wächst, und eine Kette, die sich nie schließt.
Eine synthetische Vollsicherung (synthetic full) wird aus Sicherungsdateien gebaut, die schon im Repository liegen; sie belastet die produktive Quelle also nicht, ist aber schwer für die I/O des Repositorys. Eine aktive Vollsicherung (active full) liest die ganze Quelle erneut: Sie dauert länger und belastet die Produktion, beginnt aber eine neue Kette aus frisch gelesenen Daten. Beide schließen die Kette, weshalb Forward-Incremental-Verfahren nach Zeitplan das eine oder das andere nutzen.
Was leistet Deduplizierung, und wie passt sie dazu?
Deduplizierung speichert identische Daten einmal und verweist von jeder Stelle, an der sie vorkommen, darauf. Die Dokumentation von Microsoft beschreibt sie als Suche nach doppelten Teilen eines Datensatzes, die einmal gespeichert und optional komprimiert werden. Sie arbeitet mit Chunks. Chunks fester Größe sind einfach, aber ein eingefügtes Byte verschiebt jeden Chunk dahinter; inhaltsbasiertes Chunking (Content-Defined Chunking) wählt Grenzen aus den Daten selbst, sodass die meisten Chunks gleich bleiben (FastCDC ist ein veröffentlichter Algorithmus dafür).
Wie viel sie einspart, hängt von den Daten ab. Die Dokumentation von Microsoft zu Windows Server nennt typische Einsparungen von 30 bis 50 Prozent für Benutzerdokumente und 80 bis 95 Prozent für Virtualisierungsbibliotheken. Das sind Zahlen für Dateiserver, keine für Backups, aber sie zeigen, wie weit die Spanne ist.
Inkrementelle Sicherung und Deduplizierung lösen verschiedene Probleme: Die inkrementelle Sicherung entscheidet, was das Werkzeug liest und sendet, die Deduplizierung, was das Repository behält. Mit einem deduplizierten Speicher teilen sich Sicherungsstände Chunks, statt von einer Kette abzuhängen. Jeder Sicherungsstand ist für sich vollständig, und jeder lässt sich entfernen, ohne die anderen zu zerbrechen, weil der Speicher Verweise zählt. Das verbleibende Risiko ist gemeinsam: Ein beschädigter Chunk betrifft jeden Sicherungsstand, der ihn nutzt; ein solcher Speicher braucht also Integritätsprüfungen, die die Daten zurücklesen.
Was ist Changed Block Tracking?
Eine ganze Platte zu lesen, um zu finden, was sich geändert hat, ist langsam. Hypervisoren und Speicherschichten können stattdessen aufzeichnen, welche Blöcke sich seit dem letzten Backup geändert haben; das heißt Changed Block Tracking (CBT). QEMU nennt seine Variante Dirty Bitmap, mit fester Granularität je Bitmap. Das Backup liest dann nur diese Blöcke. Geht die Aufzeichnung verloren, zum Beispiel weil eine flüchtige Bitmap beim Beenden des QEMU-Prozesses verworfen wird, was seine Dokumentation beschreibt, muss das Werkzeug die ganze Platte erneut lesen.
Welche Art soll ich wählen?
Wählen Sie nach der Einschränkung, die zuerst drückt:
- Kleine Datenmengen und einfache Restores: Vollsicherungen nach Zeitplan oder eine wöchentliche Vollsicherung mit täglichen inkrementellen oder differenziellen Sicherungen.
- Große Datenmengen und ein kurzes Fenster: inkrementelle Sicherung mit Änderungsverfolgung, in einen deduplizierten Speicher.
- Speicher ohne Deduplizierung: regelmäßige Vollsicherungen, aktiv oder synthetisch, um Ketten kurz zu halten. Eine Kette aus Hunderten Inkrementen ist ein eigenes Risiko.
- Das BSI nennt als Einflussfaktoren unter anderem die Verfügbarkeitsanforderungen (bei hohen lieber eine Vollsicherung als eine inkrementelle), das Änderungsvolumen (liegt es nahe am Datenvolumen, etwa bei Datenbanken, kann eine Vollsicherung sinnvoll sein) und die Änderungszeitpunkte (nach buchhalterischen Abschlüssen kommt nur eine Vollsicherung infrage).
- Lassen Sie Ihre Wiederherstellungsziele den Zeitplan bestimmen: Wie oft ein Backup läuft und wie lange es dauert, legt fest, wie viele Daten Sie verlieren können. Siehe RPO und RTO erklärt.
- Was Sie auch wählen, prüfen Sie es. Eine Kette oder ein Chunk-Speicher ist nur so gut wie das letzte Mal, dass er zurückgelesen wurde; siehe wie man beweist, dass ein Backup wiederhergestellt werden kann. Wo das Repository liegt, zählt ebenso: siehe Backup-Speicher wählen.
So macht es Restow
Restow verlangt nicht, dass Sie eine Backup-Art wählen. Es gibt keine Einstellung für Voll, inkrementell oder differenziell und keinen regelmäßigen Vollsicherungs-Job zu planen. Stattdessen:
Deduplizierte, verschlüsselte Chunks
Daten werden in inhaltsbasierte Chunks zerlegt (FastCDC, von 256 KiB bis 4 MiB, im Mittel etwa 1 MiB), jeder nach seinem Hash benannt, mit AES-256-GCM unter dem Schlüssel des Mandanten verschlüsselt und in Pack-Dateien von bis zu 64 MiB gepackt. Identischer Inhalt wird über Elemente und über die Zeit innerhalb eines Mandanten einmal gespeichert, nie mandantenübergreifend. Jeder Sicherungsstand listet die Chunks, die er braucht, sodass sich jeder Sicherungsstand für sich wiederherstellen oder entfernen lässt; die Garbage Collection der Speicherprüfung entfernt Chunks, die kein Sicherungsstand nutzt. Weil sich Sicherungsstände Chunks teilen, kann ein beschädigter Chunk mehrere von ihnen betreffen, und die wöchentliche und die monatliche Speicherprüfung gibt es, um genau danach zu lesen. Siehe Speicher.
Microsoft 365: inkrementell über Delta-Abfragen
Exchange-Online-Mail, Kalender und Kontakte sowie OneDrive werden über Microsoft-Graph-Delta-Abfragen gesichert, ein normaler Lauf holt also nur, was sich geändert hat; die Dokumentbibliotheken von SharePoint-Online-Websites nutzen dasselbe Delta-Verfahren wie OneDrive. Das erste Backup eines großen Tenants kann Tage dauern, weil Microsoft die Graph-API drosselt. Siehe Microsoft-365- und IMAP-Backup.
Server und Clients: restic
Der Agent für Linux und macOS sichert Dateien mit restic, das ebenfalls dedupliziert, in ein Repository je Rechner im selben Speicherziel. Er arbeitet dateibasiert: Plattenabbilder und Bare-Metal-Restore gibt es noch nicht (beides ist geplant). Siehe Server- und Client-Backup.
Dateifreigaben: inkrementell mit restic, über einen schreibgeschützten Mount
Restow sichert eine SMB-Freigabe oder einen NFS-Export ohne Agent auf dem Dateiserver. Für die Dauer eines Laufs hängt es die Freigabe schreibgeschützt ein und sichert sie mit restic in ein eigenes Repository im primären Repository. Das ist inkrementell im Sinn dieser Seite: Nach dem ersten Lauf werden Dateien, deren Größe oder Änderungszeit sich geändert hat, erneut gelesen, und Inhalt, den restic schon speichert, wird nicht ein zweites Mal gespeichert; ein normaler Lauf liest und speichert also nur, was sich geändert hat. Jeder Lauf erzeugt trotzdem einen Sicherungsstand, der für sich steht, Sie planen also nie eine Vollsicherung. Geöffnete, nicht lesbare und ausgelagerte Dateien werden übersprungen und aufgelistet, und der Lauf endet dann mit Warnungen. Wie der Agent arbeitet er dateibasiert: kein Plattenabbild. Siehe Dateifreigaben (SMB und NFS).
Proxmox VE: geänderte 4-MiB-Blöcke (eine Preview)
Die Proxmox-VE-Sicherung ist in jeder Edition eine Preview, für Proxmox VE 8.4 und neuer, und als einzige Sicherung noch nicht empfohlen. VM-Platten werden über NBD mit Dirty Bitmaps gelesen, und nur die geänderten 4-MiB-Blöcke werden gelesen und hochgeladen; Container laufen über restic. Jeder Sicherungsstand hält die vollständige Blockkarte jeder Platte, er wirkt also wie eine synthetische Vollsicherung: Jeder Sicherungsstand lässt sich für sich wiederherstellen oder entfernen. Nach einem Stopp und Start der VM, einem Backup im Stop-Modus, einer Änderung der Plattengröße oder einem Verschieben der Platte oder bei einem Backup einer ausgeschalteten VM wird die ganze Platte erneut gelesen, und nur Blöcke, deren Hash sich geändert hat, werden hochgeladen. Jedes 30. Backup einer Platte ist absichtlich ein vollständiges Lesen. Ein Proxmox-VE-Job kann außerdem eine Startprüfung ausführen (standardmäßig aus): Der Knoten stellt einen Sicherungsstand als neuen, isolierten Gast wieder her, startet ihn und zerstört ihn wieder, was zeigt, dass der Sicherungsstand startet, aber nichts über die Anwendungen darin sagt. Siehe Proxmox-VE-Backup.
Restow hat keine differenziellen Sicherungen, keine Bandunterstützung und keinen geplanten Job für aktive oder synthetische Vollsicherungen.
Häufig gestellte Fragen
Was ist der Unterschied zwischen inkrementeller und differenzieller Sicherung?
Eine inkrementelle Sicherung kopiert, was sich seit der vorherigen Sicherung beliebiger Art geändert hat; eine differenzielle (auch „differentielle“) Sicherung kopiert, was sich seit der letzten Vollsicherung geändert hat. Inkremente sind kleiner, brauchen für ein Restore aber jedes Glied der Kette. Eine differenzielle Sicherung braucht nur die letzte Vollsicherung und die neueste differenzielle, wächst aber bis zur nächsten Vollsicherung.
Ist eine Forever-Incremental-Sicherung riskant?
Sie spart am meisten Speicher und hat die längste Abhängigkeit: Ein Restore folgt der Kette von der einen Vollsicherung durch jedes Inkrement, und das Zusammenführen, das die Aufbewahrung durchsetzt, schreibt die Vollsicherung um. Das Risiko ist beherrschbar, wenn das Werkzeug die Kette prüft und Sie Backups zurücklesen und Restores testen. Ein Werkzeug, das deduplizierte Chunks speichert, vermeidet die Kette, aber dann teilen sich Sicherungsstände Chunks.
Ersetzt Deduplizierung inkrementelle Backups?
Nein. Inkrementelle Sicherung verringert, was gelesen und übertragen wird; Deduplizierung verringert, was gespeichert wird. Viele Werkzeuge kombinieren beides: Sie lesen nur, was sich geändert hat, und speichern nur Chunks, die sie noch nicht gespeichert haben.
Brauche ich weiterhin regelmäßig eine Vollsicherung?
Das hängt davon ab, wie das Werkzeug Daten ablegt. Wo jedes Inkrement von einer Kette abhängt, hält eine regelmäßige Voll- oder synthetische Vollsicherung die Kette kurz. Ein vollständiges Lesen der Quelle gleicht außerdem das Repository mit der Quelle ab; Restow liest deshalb eine Proxmox-VE-Platte bei jedem 30. Backup vollständig.
Was ist Changed Block Tracking?
Eine Aufzeichnung, die der Hypervisor oder die Speicherschicht führt, welche Blöcke einer Platte sich seit dem letzten Backup geändert haben, damit ein Backup nur diese liest. QEMU, das Proxmox VE nutzt, nennt sie Dirty Bitmap. Geht die Aufzeichnung verloren, muss das Backup die ganze Platte erneut lesen.
Quellen
Gelesen am 16. Oktober 2026.
- BSI: Umsetzungshinweise zum Baustein CON.3 Datensicherungskonzept. Volldatensicherung, inkrementelle und differenzielle Datensicherung, Image-Datensicherung und die Einflussfaktoren für die Wahl
- Veeam Best Practice Guide: Backup job methods (englisch). Forward Incremental mit synthetischen oder aktiven Vollsicherungen, Forever Forward Incremental und ihre Abwägungen
- Veeam Backup & Replication Quick Start Guide: Backup methods (englisch). Definitionen von Forever Forward Incremental, aktiver Vollsicherung und synthetischer Vollsicherung
- Microsoft Learn: Differenzielle Sicherungen (SQL Server). Eine differenzielle Sicherung basiert auf der letzten vollständigen Sicherung und wächst bis zur nächsten
- Microsoft Learn: Datendeduplizierung (Übersicht, Windows Server). Was Deduplizierung ist und typische Einsparungen nach Inhaltstyp; die Zahlen gelten für Dateiserver
- Xia, W. et al.: FastCDC: a fast and efficient content-defined chunking approach for data deduplication (USENIX ATC 2016, englisch). Der Chunking-Algorithmus, den Restow nutzt
- QEMU-Dokumentation: Dirty bitmaps and incremental backup (englisch). Wie eine Dirty Bitmap geänderte Bereiche markiert und wann sie verloren geht
- Microsoft Learn: Verwenden einer Delta-Abfrage zum Nachverfolgen von Änderungen in Microsoft Graph-Daten. Wie Microsoft Graph nur zurückgibt, was sich seit der letzten Abfrage geändert hat