Das folgende Beispiel arbeitet mit einer Image-Datei, damit es überall ausprobiert werden kann. Mit einem Blockgerät (/dev/vg0/data) ändert sich nur die Angabe bei --source.
3.1 Testdaten anlegen#
dd if=/dev/urandom of=data.img bs=1M count=16
dd if=/dev/zero of=data.img bs=1M seek=4 count=4 conv=notrunc # 4 MiB Nullen mittendrin
mkdir backup3.2 Erste Sicherung#
bkp_agent --source data.img --out backup --name data --verifyAusgabe:
[bkp_agent] INFO source is not an LVM logical volume: backing it up directly (no snapshot)
[bkp_agent] INFO created the store backup/default.cbs (id hash blake3, encryption none, chunks 65536/262144/1048576,
segments of 1073741824 bytes)
[bkp_agent] INFO backing up data.img (16777216 bytes) into backup/default.cbs: id hash blake3, 2 worker(s)
[bkp_agent] INFO verify: the snapshot reads back completely from backup/default.cbs
[bkp_agent] INFO done: full run 20261015T121825Z-6aa5d6f2-8419-482a-ab3f-0373e33b449d in backup/default.cbs:
source 16777216 bytes, data 13631488, holes 3145728 (fs-free 0); chunks 44, new 44 (0.0% deduplicated);
12587566 bytes sent, 12587566 newly storedDie erste Sicherung legt den Store backup/default.cbs an (ein anderer Name mit --store). So liest sich die Zusammenfassung: Von 16 MiB Quelle sind 13 MiB Daten und 3 MiB Loch (Nullen, nur vermerkt). Die Daten ergaben 44 Chunks, alle neu. Gespeichert wurden 12 MiB, weil Zufallsdaten nicht komprimierbar sind; bei echten Daten ist der Wert kleiner. --verify liest die ganze Sicherung nach dem Abschluss aus dem Store zurück und prüft jeden Chunk gegen seine ID.
Hinweis: Dass vom 4 MiB großen Nullbereich nur 3 MiB als Loch zählen, ist kein Fehler: Der Rest steckt in den Chunks rechts und links davon, deren Grenzen sich nach dem Inhalt richten.
3.3 Weitere Sicherungen#
# ... 1 MiB der Daten ändert sich ...
bkp_agent --source data.img --out backup --name dataAusgabe:
[bkp_agent] INFO done: incremental run 20261015T121831Z-8c47f436-cdc7-4638-a3f8-d347e0c5ba7c in backup/default.cbs:
source 16777216 bytes, data 13631488, holes 3145728 (fs-free 0); chunks 44, new 8 (81.8% deduplicated);
2262373 bytes sent, 2262373 newly storedJede weitere Sicherung ist derselbe Befehl. Der Agent liest die ganze Quelle, erkennt aber 36 der 44 Chunks wieder und speichert nur die 8 neuen (2,2 MiB). Trotzdem ist der neue Run ein vollständiger Stand: Er lässt sich ohne den ersten wiederherstellen, und der erste lässt sich löschen, ohne den zweiten zu beschädigen. Eine Angabe wie --type ist nicht nötig (Standard inc); --type full beginnt eine neue, unabhängige Generation (Kapitel 6).
3.4 Was im Store liegt#
bkp_restore --store backup/default.cbs --listAusgabe:
RUN CREATED NAME TYPE SOURCE DATA SENT NEW STATUS
20261015T121825Z-6aa5d6f2-8419-482a-ab3f-0373e33b449d 2026-10-15 14:18:25 data Full 16.0 MiB 13.0 MiB 12.0 MiB 12.0 MiB ok
20261015T121831Z-8c47f436-cdc7-4638-a3f8-d347e0c5ba7c 2026-10-15 14:18:31 data Incremental 16.0 MiB 13.0 MiB 2.2 MiB 2.2 MiB ok
every run restores on its own (full and incremental alike), a VM run one disk at a time (--disk)Je Run stehen dort: Zeitpunkt (Ortszeit), Backup-Name, Full/Incremental, Größe der Quelle, Daten (ohne Löcher), übertragene und neu gespeicherte Bytes. Auf der Platte sieht der Store so aus:
Aufbau eines Stores
backup/default.cbs/
store.json ID-Hash, Verschlüsselung, Chunk-Größen (beim Anlegen fest)
packs/<xx>/<id>.pack Chunks und Verwaltungsobjekte, je ca. 64 MiB
runs/<zeit>-<uuid>.run eine kleine Datei je Sicherung (Commit-Punkt)
index.lmdb Index (Cache, wird aus den Packs neu aufgebaut)Achtung: Ein Store ist eine Einheit. Kopiere oder lösche nie einzelne Dateien darin von Hand; für Kopien gibt es bkp_maintenance mirror, für einzelne Runs export und zum Löschen prune bzw. delete (Kapitel 10).
3.5 Wiederherstellen#
bkp_restore --store backup/default.cbs --name data --target restored.img
cmp data.img restored.img && echo IDENTISCHAusgabe:
[bkp_restore] INFO restoring run 20261015T121831Z-8c47f436-cdc7-4638-a3f8-d347e0c5ba7c ('data' of 2026-10-15 14:18:31,
16777216 bytes) from backup/default.cbs to restored.img
[bkp_restore] INFO done: 16777216 bytes restored (data 13631488, holes 3145728), 44 chunks, 12583143 stored bytes read
IDENTISCH--name nimmt den neuesten Run dieses Namens. Einen älteren Stand wählt --at "2026-10-15 14:20" (der neueste Run bis zu diesem Zeitpunkt) oder --run <run> mit dem Namen aus --list. Jeder Chunk wird beim Lesen gegen seine ID geprüft; eine eigene Prüfoption braucht der Restore nicht (Kapitel 7).
3.6 Wichtige Optionen des Agents#
| Option | Bedeutung |
|---|---|
--store <name> | Name des Stores (Standard default), liegt unter <out>/<name>.cbs. Ähnliche Rechner teilen sich sinnvollerweise einen Store |
--type inc|full | inc (Standard): normaler Lauf. full: beginnt eine neue Store-Generation (Kapitel 6). diff gibt es nicht mehr |
--store-generation none|<n>d|<n>m | automatisch eine neue Generation, wenn die aktuelle älter ist (Standard none) |
--chunk-size <avg> | mittlere Chunk-Größe eines neuen Stores bzw. einer neuen Generation (Zweierpotenz, Standard 256K; Kapitel 25) |
--hash sha256|blake3|xxh3-128 | ID-Hash eines neuen Stores (siehe unten) |
--threads <n>, --chunk-threads <n> | Worker (Hash und Kompression) bzw. gleichzeitig gechunkte 1-GiB-Segmente |
--compression zstd|lz4|none, --level <n> | Kompression je neuem Chunk; Standard zstd, Level 3 |
--max-level <n> | adaptive Erhöhung des zstd-Levels bis höchstens n (max. 22): das Level steigt, solange der Schreiber der Engpass ist und die Worker Luft haben |
--verify | liest die ganze Sicherung nach dem Abschluss aus dem Store zurück; nur lokale Stores, bei einem Server übersprungen |
--no-fs-bitmap | auch freie Bereiche lesen und sichern: der Restore ist dann bitgleich zum Gerät |
--retention <spec>, --retention-class <klasse> | Aufbewahrung dieser Sicherung (7d, 5w, 12m, 1y, forever oder GFS wie gfs:7d,4w,12m,5y), steht im Run (Kapitel 10) |
--index-dir <dir> | Index des Stores woanders ablegen (z. B. SSD); Pflicht, wenn der Store auf NFS/SMB liegt |
--background | drosselt die Sicherung selbst, wenn die Maschine ausgelastet ist |
--no-progress | keinen Fortschritt melden (kein Laufkanal, Kapitel 13); ein solcher Lauf ist dann auch nicht pausier- oder drosselbar |
Achtung: Freie Bereiche werden bei ext2/3/4 und NTFS nicht gesichert und beim Restore mit Nullen gefüllt. Das wiederhergestellte Dateisystem ist identisch (fsck sauber, alle Dateien gleich), die Rohdaten aber nicht: eine SHA-256 über das ganze Gerät weicht ab. Für eine bitgleiche Kopie --no-fs-bitmap verwenden.
Hinweis: Optionen aus Version 1 (--parent, --block-size, --search-dir, --type diff, --resume verify|trust) werden mit einem Hinweis auf den Ersatz abgewiesen, zum Beispiel: --type diff no longer exists: every backup can be restored on its own; for an independent base use --type full.
3.7 ID-Hash wählen (--hash)#
Jeder Chunk wird über seinen Inhalts-Hash erkannt, seine ID. Gleiche ID heißt gleicher Inhalt: darauf beruht die Deduplizierung, und jedes Lesen (Restore, --verify, scrub) prüft den Inhalt gegen die ID. Das Verfahren gilt für einen ganzen Store und wird beim Anlegen festgelegt (id_hash in store.json):
--hash | Eigenschaften |
|---|---|
sha256 | kryptografisch; mit SHA-NI ca. 2 GB/s je Kern, ohne deutlich weniger, dann oft der CPU-Engpass |
blake3 (Standard) | kryptografisch (256 Bit), nutzt SSE4.1/AVX2/AVX-512; auf modernen CPUs kaum langsamer als xxh3 und ein Vielfaches schneller als SHA-256 ohne SHA-NI |
xxh3-128 | nicht kryptografisch (128 Bit), am schnellsten. Zufällige Kollisionen sind praktisch ausgeschlossen, gezielt erzeugte nicht |
Tipp: Welches nehmen? sha256 und blake3 sind auch dann sicher, wenn sich Agents einen Store teilen, die einander nicht vertrauen: Niemand kann einen Chunk bauen, der die ID eines fremden Chunks hat. xxh3-128 ist nur für Stores gedacht, in die ausschließlich vertrauenswürdige Agents schreiben. Wer den Inhalt einer Quelle steuert, könnte sonst einen Chunk mit derselben ID unterschieben, der dann an Stelle des echten in fremden Sicherungen landet.
Der Standard blake3 ist für neue Stores meist die beste Wahl. Ohne --hash legt ein Lauf einen neuen Store mit blake3 an und übernimmt sonst das Verfahren des bestehenden Stores; Stores von vor 2.0.0-alpha.017 behalten sha256.
bkp_agent --source data.img --out backup --store fast --name data --hash blake3
bkp_agent --source data.img --out backup --store fast --name data # übernimmt blake3 vom StoreOhne --hash übernimmt ein Lauf das Verfahren des bestehenden Stores; ein ausdrücklich angegebenes, abweichendes --hash wird abgewiesen (wie ein falscher Schlüssel). Gewechselt wird über eine neue Generation: --type full --hash blake3 (Kapitel 6). In verschlüsselten Stores wird die ID mit einem aus dem Store-Schlüssel abgeleiteten Schlüssel gebildet; gleiche IDs verraten dann ohne Schlüssel nichts über den Inhalt. In den Konfigurationsdateien heißt der Schlüssel hash.