Das vollständige Format steht in docs/store-format.txt. Kurzfassung:
B.1 Objekte und Packs#
Alle Objekte sind unveränderlich und inhaltsadressiert. Ein BLOB ist ein Chunk, ein TREE eine Liste von Verweisen (Manifest-Segmente, Run-Wurzel). Die ID ist der ID-Hash (id_hash in store.json) über den Inhalt, bei verschlüsselten Stores mit einem aus dem Schlüssel abgeleiteten Schlüssel (HMAC-SHA256, keyed BLAKE3 bzw. XXH3 mit Secret). Jedes Objekt ist komprimiert und ggf. verschlüsselt; beim Lesen wird es immer gegen seine ID geprüft. TREEs tragen ihre Verweise im Klartext, damit prune, mirror und export ohne Schlüssel arbeiten; sichtbar sind dabei nur Struktur und Größen, nie Inhalte. Packs (packs/<xx>/<pack>.pack) enthalten Objekte hintereinander, je mit Kopf und CRC32C, und einen Index am Pack-Ende.
B.2 Runs und Manifeste#
Ein Run (runs/<zeit>-<uuid>.run) ist eine JSON-Datei, die atomar als Letztes geschrieben wird (Commit-Punkt). Ein Block-Snapshot beschreibt die Quelle in Segmenten zu 1 GiB; jedes Segment ist eine Liste von Extents (Chunk oder Loch). Chunk-Grenzen: FastCDC mit fester Gear-Tabelle, Parameter min/avg/max aus store.json. Ein VM-Run (kind: vm, Proxmox/Xen) hat eine Wurzel mit der Konfiguration und je Disk einem Block-Snapshot. Ein Archiv (.cba) enthält einen Run mit allen nötigen Objekten in Restore-Reihenfolge, Index und SHA-256 am Ende; es ist von vorn nach hinten lesbar (Band, Pipe).
B.3 Netzwerkprotokoll#
Frames mit CRC32C über TLS (Protokollversion 4). HELLO mit API-Key; OBJ_OPEN öffnet oder legt einen Store an; OBJ_HAVE fragt, welche Objekte schon da sind; OBJ_PUT/OBJ_GET übertragen Datensätze über beliebig viele Frames; OBJ_COMMIT schreibt den Run, OBJ_LIST_RUNS listet die Runs, OBJ_FLUSH lässt sich die bisherigen Daten bestätigen; OBJ_TYPES/OBJ_AUX dienen dem Spiegeln. Anhalten: Ein Server mit der Fähigkeit BKP_CAP_HOLD nimmt OBJ_HOLD entgegen, mit dem der Client einen angehaltenen Lauf vor dem letzten OBJ_FLUSH meldet (das Verbindungsende ohne Commit ist dann kein Fehler). Hält der Target-Administrator eine Sicherung an, hängt der Server einem Client mit BKP_CAP_CLIENT_HOLD einen Halt-Block (Fortsetzungszeit, Verteilung, Art, von wem, Grund) an OBJ_PUT_ACK bzw. PONG; folgt der Client nicht binnen 120 Sekunden, schließt der Server die Verbindung. Ein erneutes Öffnen einer angehaltenen Sicherung beantwortet er mit BKP_ERR_HELD. Ein Agent oder Server von Version 1 wird beim Verbindungsaufbau abgewiesen.