Umstieg für FULL/DIFF/INC-Kenner

Zum Inhaltsverzeichnis

Version 1 sicherte in Ketten: eine FULL-Sicherung, darauf aufbauend DIFF- und INC-Sicherungen, jede als Paar aus Meta- und Image-Datei (.infb/.csfb, .indb/.csdb, .inib/.csib). Version 2 speichert stattdessen deduplizierte Runs in Stores. Das alte Format ist nicht mehr lesbar, außer mit bkp_restore_legacy. Dieses Kapitel übersetzt die vertrauten Begriffe und Abläufe und endet mit einer Checkliste für das Update.

27.1 Gegenüberstellung#

27.2 Was beim Restore anders ist#

• Es gibt keine Kette mehr, die vollständig vorliegen muss. Ein Run verweist direkt auf alle seine Chunks; der älteste ist so schnell zurückgespielt wie der neueste.
• Einen Zeitpunkt wählt --at statt der UUID einer bestimmten Sicherung; --run nimmt den Namen aus --list.
• Fehlt ein Chunk, scheitert nicht der ganze Restore: der Bereich wird mit Nullen gefüllt und gemeldet (Teil-Restore, Exit 3), oder er kommt aus einem anderen Sink.

27.3 Aufbewahrung und Speicherfreigabe#

In Version 1 blieb eine Kette, bis ihr letztes Glied ablief, weil jede INC ihre Vorgänger brauchte; Platz wurde frei, wenn eine ganze Kette gelöscht wurde. In Version 2 hat jeder Run seine eigene Aufbewahrung, und prune löscht abgelaufene Runs einzeln. Danach entfernt prune die Daten, die kein verbliebener Run mehr braucht (Garbage Collection).

• Ein abgelaufener Run lässt sich jederzeit löschen, auch wenn ältere oder jüngere Runs bleiben. Es gibt keine Abhängigkeiten mehr.
• Löschen gibt nur Platz frei, wenn die Chunks des Runs nicht noch anderswo gebraucht werden. Bei stabilen Daten ist das wenig: das meiste teilen sich die Runs.
• Schutzfristen: die neueste Sicherung je Name bleibt immer; Packs jünger als --gc-min-age (24 h) werden nie angefasst.

27.4 Schadensbetrachtung#

In einer Kette machte ein beschädigter Block in der FULL jeden darauf aufbauenden Stand an dieser Stelle unbrauchbar, und eine neue FULL war die Rückfallebene. Im Store teilen sich viele Runs einen Chunk; ein beschädigter, oft verwendeter Chunk trifft deshalb ebenfalls viele Runs. Dagegen gibt es mehrere Schutzschichten:

• Jedes Objekt hat eine Prüfsumme und wird beim Lesen gegen seine ID geprüft; Schäden werden immer erkannt, nie stillschweigend zurückgeschrieben.
• scrub findet Schäden früh, repair ersetzt sie aus einer zweiten Kopie (zweiter Sink oder Spiegel).
• Der Teil-Restore liefert den Rest einer beschädigten Sicherung und meldet genau, welche Bereiche fehlen.
• Eine neue Generation (--type full oder --store-generation) ist wie früher eine neue FULL: eine Basis, die keine Daten mit den älteren teilt.

27.5 Platzanzeige#

Früher war der Platz einer Sicherung die Größe ihrer Dateien. Heute zeigt bkp_restore --list je Run die Spalten DATA (Daten des Stands), SENT (übertragen) und NEW (neu gespeichert). NEW entspricht am ehesten der Größe einer früheren INC. bkp_maintenance store-info zeigt die Summe der Daten aller Runs gegenüber den gespeicherten Bytes (Deduplizierungsfaktor) und mit --exclusive je Backup-Name, was nur seine Runs belegen, also was das Löschen dieses Namens frei machen würde.

27.6 Zeitplan vorher und nachher#

27.7 Checkliste für das Update beim Kunden#

1. Platz einplanen: Die erste Sicherung jedes Rechners in den neuen Store dauert so lange wie eine FULL und braucht deren Platz; erst ab der zweiten wird nur noch Neues gespeichert. Die alten Ketten liegen bis zu ihrem Ablauf daneben.
2. Konfigurationen anpassen: block-size=, parent=, type=diff, resume=verify|trust, out-encryption=/target-encryption= (jetzt [sink:] mit encryption=/key=), no-vmconfig/no-domconfig, search-dir=, maint-synthetic-full/maint-recompress-Jobs und {meta}/{img} im Target-Scheduler werden abgewiesen (als unbekannter Schlüssel oder mit einem Hinweis auf den Ersatz). bkp_sched validate und bkp_target --sched-validate prüfen die Job-Konfigurationen; ein Profil prüft man mit einem Probelauf von Hand.
3. Hash und Chunk-Größe festlegen: beides gilt ab dem ersten Lauf für den Store. Für neue Stores --hash blake3, die Chunk-Größe zunächst beim Standard lassen und später nach der Empfehlung von store-info umstellen.
4. bkp_restore_legacy bereithalten (Setup-Komponente legacy), am besten auf dem Backup-Server, wo die alten Dateien liegen: das neue bkp_target spricht das alte Protokoll nicht.
5. Alte Dateien auslaufen lassen: gelöscht werden sie mit bkp_restore_legacy prune bzw. delete, nicht mit bkp_maintenance.

Alte Sicherungen lesen und löschen

bkp_restore_legacy list /backup                                                   # alte Sicherungen anzeigen
bkp_restore_legacy restore --meta /backup/data-20260101T020000Z.inib --target /dev/vg0/data_restored
bkp_restore_legacy prune --search-dir /backup --dry-run                           # abgelaufene alte Ketten