Die Backup-Dokumentation verwendet die Begriffe „voll" und „inkrementell" oft unscharf, und die Implementierungen unterscheiden sich zwischen den Anbietern so stark, dass gemeinsame Annahmen scheitern. Dieser Artikel definiert das klassische Vokabular, erklärt, wie StateWarden Backups tatsächlich ausführt, und zeigt, wie die Größenangaben im Dashboard zu interpretieren sind.
1. Das klassische Vokabular
Vollbackup
Eine vollständige, in sich geschlossene Kopie der Quelle zu einem bestimmten Zeitpunkt. Jeder Block wird gelesen und übertragen. Ein Vollbackup lässt sich eigenständig wiederherstellen, ohne Abhängigkeit von einem anderen Backup - erkauft durch die höchste I/O-Last, das größte Übertragungsvolumen und die längste Backup-Fenster-Dauer.
Inkrementelles Backup
Eine Erfassung nur der Daten, die sich seit dem letzten Backup beliebiger Art (voll oder inkrementell) geändert haben. Inkrementelle Backups sind schnell und klein, bilden aber in klassischen Implementierungen eine Kette: Eine Wiederherstellung erfordert das letzte Vollbackup plus jedes danach erstellte inkrementelle Backup. Geht irgendein Glied der Kette verloren oder wird beschädigt, ist jeder spätere Wiederherstellungspunkt betroffen.
Differentielles Backup
Eine Erfassung aller Daten, die sich seit dem letzten Vollbackup geändert haben. Differentielle Backups wachsen mit jedem Lauf, halten die Wiederherstellungsabhängigkeit aber kurz: das letzte Vollbackup plus das jüngste differentielle Backup. StateWarden verwendet die differentielle Strategie nicht; sie ist hier nur der Vollständigkeit des Vokabulars halber aufgeführt.
| Strategie | Lesevolumen pro Lauf | Klassische Wiederherstellungsabhängigkeit |
|---|---|---|
| Voll | 100 % der Quelle | In sich geschlossen |
| Inkrementell | Änderungen seit dem letzten Backup | Vollständige Kette (Vollbackup + alle inkrementellen) |
| Differentiell | Änderungen seit dem letzten Vollbackup | Letztes Vollbackup + jüngstes differentielles |
2. Wie StateWarden tatsächlich arbeitet: Forever-Incremental
StateWarden verarbeitet Volumes auf Blockebene (siehe Smart NTFS and Block-Level Backups). Der Agent zerlegt den Datenstrom in Chunks, hasht und verschlüsselt die Chunks und lädt nur diejenigen Chunks hoch, die im deduplizierten Chunk-Speicher des Realms auf der Data Plane (Driad) noch nicht vorhanden sind. Die Chunk-Identität ist inhaltsbasiert; identische Daten werden daher nur einmal gespeichert, unabhängig davon, welches Gerät oder welches Backup sie erzeugt hat (siehe Architecture Overview: Artemis, Driad, and the Agent).
Nach der anfänglichen Baseline läuft jedes geplante Backup inkrementell: Der Agent liest nur die Blöcke, die sich geändert haben, und überträgt nur die daraus resultierenden einzigartigen Chunks. Es gibt keine geplante Rotation periodischer Vollbackups; im Normalbetrieb wird eine Quelle exakt einmal vollständig gelesen (Ausnahmen in Abschnitt 4).
Der entscheidende Unterschied zum klassischen Modell liegt auf der Wiederherstellungsseite. Obwohl jeder Lauf nur geänderte Chunks speichert, wird jeder Wiederherstellungspunkt im Dashboard und auf der Seite Daten wiederherstellen als vollständiger, unabhängig nutzbarer Snapshot der Quelle präsentiert, synthetisiert aus dem Chunk-Speicher. Die Konsequenzen sind operativ, nicht kosmetisch:
- Es gibt keine inkrementelle Kette, die brechen könnte. Jeder einzelne Wiederherstellungspunkt genügt für sich allein.
- Der Ablauf oder die Löschung eines alten Wiederherstellungspunkts beeinträchtigt nicht die Integrität neuerer; Chunks, auf die verbleibende Wiederherstellungspunkte noch verweisen, bleiben erhalten.
- Das Aufbewahrungsmanagement erfordert niemals das erneute Erstellen eines Vollbackups, um eine Kette gültig zu halten.
Der Backup-Verlauf protokolliert in der Spalte Typ, welche Strategie jeder Lauf verwendet hat: Voll, Inkrementell oder Synthetisch Voll. Ein Synthetisch Voll entsteht bei Images ganzer Festplatten: Der Agent erfasst das Festplattenlayout und alle Partitionen mit inkrementellen Lesevorgängen, wo Change Tracking verfügbar ist, und das Ergebnis ist ein vollständiges, bootfähiges Festplatten-Image für die Bare Metal Recovery (siehe Bare Metal Recovery Walkthrough).
3. Was CBT ist - und was nicht
Changed Block Tracking (CBT) ist ein Beschleuniger für die Änderungserkennung, kein Speicherformat und kein Backup-Typ. Smart CBT von StateWarden nutzt die nativen Mechanismen des Betriebssystems:
- Windows: das NTFS-USN-Journal (Update Sequence Number).
- Linux: era-basiertes Device-Mapper-Tracking (
dm-era).
CBT beantwortet exakt eine Frage: Welche Blöcke muss der Agent für diesen Lauf lesen? Statt das Volume nach Änderungen zu durchsuchen, fragt der Agent das Betriebssystem nach der Liste der seit dem letzten Snapshot geänderten Blöcke und liest nur diese. Das reduziert die Erkennungsphase von einem vollständigen Volume-Scan auf eine Metadaten-Abfrage.
CBT ändert nichts daran, was gespeichert wird. Der Speicherpfad ist bei jedem Lauf identisch: zerlegen in Chunks, hashen, deduplizieren, verschlüsseln, einzigartige Chunks hochladen. Ein mit CBT erstellter Wiederherstellungspunkt ist kein Teilbackup; er ist ein vollständiges Image der Quelle zu einem bestimmten Zeitpunkt, zusammengesetzt aus demselben Chunk-Speicher wie jeder andere Wiederherstellungspunkt.
Zwei praktische Folgerungen:
- CBT wird pro Volume im Dashboard gesteuert, das auch den Tracking-Status pro Volume meldet. Wo CBT nicht aktiviert werden kann (zum Beispiel auf roh verschlüsselten Volumes wie BitLocker oder LUKS, wo die Änderungserkennung auf Blockebene wirkungslos ist), wird das Volume stattdessen mit vollständigen Lesevorgängen gesichert.
- Da CBT nur die Erkennung beschleunigt, verändert ein Fallback auf einen vollständigen Lesevorgang Laufzeit und I/O-Last, niemals die Vollständigkeit der Wiederherstellung.
Aktivieren, Deaktivieren und die Fehlerbehebung von CBT pro Volume behandelt Smart CBT: Incremental Backups.
4. Wann dennoch vollständig gelesen wird
In StateWarden beschreibt „voll" die Leseseite: Der Agent liest die gesamte Quelle sequenziell, statt das Change Tracking zu konsultieren. Ein vollständiger Lesevorgang findet in diesen Fällen statt:
- Erstes Backup einer Quelle. Es existiert noch keine Tracking-Baseline, daher liest der erste Lauf immer das gesamte Volume und erstellt die Baseline.
- CBT nicht verfügbar oder deaktiviert. Ist das Tracking für das Volume nicht aktiviert oder der OS-Mechanismus nicht nutzbar, fällt der Agent bei jedem Lauf auf das vollständige Lesen der Quelle zurück.
- Nach einem erzwungenen Vollbackup. Ein erzwungenes Vollbackup liest die Quelle erneut und baut die Tracking-Baseline neu auf (siehe Abschnitt 5).
- Ungültiger Tracking-Status. Das Deaktivieren von CBT verwirft die Tracking-Metadaten, und größere Systemänderungen (zum Beispiel ein Kernel-Upgrade oder eine Bare-Metal-Wiederherstellung) können sie ungültig machen; der nächste Lauf erstellt mit einem vollständigen Lesevorgang eine neue Baseline.
Selbst während eines vollständigen Lesevorgangs bleibt der Upload dedupliziert: Der Agent überträgt nur Chunks, die der Speicher noch nicht enthält. Das erneute vollständige Lesen eines unveränderten Volumes kostet daher I/O und Zeit, aber kaum Bandbreite und keinen zusätzlichen Speicher.
5. Schlüsselrotation und erzwungene Vollbackups
Backups werden mit dem Verschlüsselungsschlüssel des Realms verschlüsselt, und jeder Wiederherstellungspunkt ist an den Schlüssel gebunden, unter dem er geschrieben wurde. Wenn der Schlüssel auf Realm-Ebene auf der Seite Sicherheit & Compliance rotiert wird (siehe Global Keys vs Device Keys: Enterprise Encryption Strategy):
- Wiederherstellungspunkte, die unter dem vorherigen Schlüssel geschrieben wurden, werden im Dashboard mit dem Badge VERALTETER SCHLÜSSEL markiert. Sie bleiben gelistet, aber ihre Wiederherstellung erfordert den vorherigen Recovery-Schlüssel.
- Der an den vorherigen Schlüssel gebundene inkrementelle Tracking-Status wird beim nächsten Lauf verworfen. Das erste Backup nach einer Rotation läuft automatisch als vollständige Baseline.
- Die Aktion Backup jetzt starten bietet die Option Vollbackup erzwingen für Fälle, in denen ein Gerät sofort neu baseliniert werden soll statt beim nächsten geplanten Lauf. Das Erzwingen eines Vollbackups liest die gesamte Quelle und setzt das Change Tracking zurück; der Upload bleibt dedupliziert.
Erwarten Sie, dass der belegte Speicher nach einer Rotation vorübergehend wächst: Unter dem vorherigen Schlüssel geschriebene Daten bleiben erhalten, bis die betroffenen Wiederherstellungspunkte ablaufen oder entfernt werden, sodass dieselben logischen Daten unter beiden Schlüsseln Platz belegen können, bis abgelöste Daten per Garbage Collection freigegeben werden.
6. Die Kennzahlen lesen
Drei Größenangaben begleiten jedes Backup. Sie messen Unterschiedliches, und wer sie verwechselt, zieht falsche Schlüsse über Zustand und Kosten der Backups.
| Konzept | Dashboard-Bezeichnung | Was es misst |
|---|---|---|
| Quellgröße | Wiederherstellungsgröße | Die unkomprimierte Größe der Quelldaten bei Wiederherstellung auf Festplatte. Über alle Läufe konstant, unabhängig vom Backup-Typ; dient der Prüfung, ob das Backup den erwarteten Umfang abdeckt. |
| Übertragene Größe | Deduplizierte Datengröße | Die tatsächlich an den Speicherknoten gesendeten Daten nach Deduplizierung und Kompression. Deshalb kann ein Lauf gegen eine 100-GB-Quelle in Sekunden abgeschlossen sein: Nur die geänderten, noch nicht gespeicherten Chunks überqueren das Netzwerk. |
| Belegte Größe | Kontingent / Backups + Metadaten | Der physisch belegte Platz auf der Speicherseite durch Ihre verschlüsselten Chunks und Backup-Metadaten, gemessen nach Deduplizierung und Kompression. Dies ist die abrechnungsrelevante Größe (siehe Understanding Quotas and Fair Use). |
Zusammen gelesen beschreiben die drei Angaben die Effizienz der Strategie auf einen Blick: Die Wiederherstellungsgröße bleibt konstant, die übertragene Größe folgt der tatsächlichen Änderungsrate des Workloads, und die belegte Größe wächst nur mit echt neuen, nicht duplizierten Daten. Ein plötzlicher Sprung der übertragenen Größe bei einem inkrementellen Lauf bedeutet, dass sich der Workload erheblich geändert hat oder ein vollständiger Lesevorgang stattgefunden hat; es bedeutet nicht, dass der Wiederherstellungspunkt mehr Daten enthält.