BAK-02: objekt-storage-backup-snapshots

restic statt Eigenbau (Content-defined Chunking fuer Dedup, verschluesseltes
Repository ab Werk, geprueftes Tooling). internal/objectbackup wrapt
restic init/backup/check/forget ueber os/exec, cmd/objectbackup-cli fuer
systemd-Timer (stuendliche Sicherung, woechentliche Vollstaendigkeitspruefung,
taegliche Rotation).

Auf 192.168.1.131 real verifiziert (kein Mock): zweiter Lauf gegen
unveraenderten Bestand ueberraegt nichts (files_new=0), zwei identische
Dateien erzeugen nachweislich nur 1 data_blob (echter Dedup-Nachweis),
absichtlich gekipptes Byte in einer Pack-Datei wird von check --read-data
zuverlaessig erkannt. Echt verdrahtet: 3 systemd-Timer installiert+
aktiviert, jeder Dienst einmal end-to-end via systemctl start ausgeloest.

Im selben Rutsch BAK-01-Fund korrigiert: NEXARCH_BACKUP_DIR zeigte auf
/var/backups/nexarch (Root-Dateisystem, kein Dataset) statt auf das
persistente ZFS-Dataset /var/nexarch-archiv - korrigiert, erneut ausgeloest,
landet nachweislich am richtigen Ort. objectbackup-cli-Repository liegt von
Anfang an korrekt dort.

Siehe archive/docs/BAK-02-PRUEFPROTOKOLL.md fuer alle Pruefungsergebnisse.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HhgFcLS8tYMhDJpP74C6AQ

archive/README.md

@@ -12,7 +12,7 @@ Datenbank-Backup-Strategie) — weitere Bausteine folgen ticketweise.
 ```bash
 export NEXARCH_BACKUP_PG_USER=nexarch_backup
 export NEXARCH_BACKUP_PG_PASSWORD=...
-export NEXARCH_BACKUP_DIR=/var/backups/nexarch
+export NEXARCH_BACKUP_DIR=/var/nexarch-archiv/backups/postgres   # NICHT auf einem ephemeren Test-Dataset (siehe Betrieb)
 export NEXARCH_BACKUP_KEEP_GENERATIONS=7   # optional, Default 7
 
 backup-cli full          # neue Vollsicherung + Verifikation
@@ -26,6 +26,35 @@ Replikationsverbindung), und `summarize_wal = on` muss serverseitig gesetzt
 sein (PostgreSQL 17s natives inkrementelles Backup, keine WAL-Archivierung
 nötig).
 
+## BAK-02: Objekt-Storage-Backup
+
+`cmd/objectbackup-cli` sichert einen lokalen Verzeichnisbaum (den
+FDN-03-`LocalDriver`-Basisordner direkt, oder — für S3-gestützte
+Deployments — einen vorgelagerten `rclone`-Spiegel) mit
+[restic](https://restic.net) (Content-defined Chunking, verschlüsseltes
+Repository, geprüftes Tooling statt Eigenbau):
+
+```bash
+export NEXARCH_OBJECTBACKUP_REPO_DIR=/var/nexarch-archiv/backups/objects
+export NEXARCH_OBJECTBACKUP_PASSWORD=...
+export NEXARCH_OBJECTBACKUP_KEEP_SNAPSHOTS=30   # optional, Default 7
+
+objectbackup-cli backup /var/nexarch-objects   # Sicherung + Verifikation
+objectbackup-cli check                          # vollständiges Lesen aller Datenblöcke
+objectbackup-cli rotate                          # restic forget --keep-last N --prune
+```
+
+## Betrieb: Backup-Zielverzeichnis
+
+Backup-Ziele liegen unter `/var/nexarch-archiv/` (persistentes ZFS-Dataset,
+`zfs/data/subvol-1131-disk-0` auf 192.168.1.131), NIEMALS unter
+`/var/nexarch-test/` (ephemeres Dataset, wird von den `reset-test-env.sh`-
+Skripten der anderen Module geleert). ZFS-seitige Snapshots/Replikation
+dieses Datasets sind ein eigenständiges Infra-Runbook (siehe
+`../../STORAGE-KONZEPT.md` Abschnitt 7), kein Ticket-Code — `zfs
+dedup=on` bewusst NICHT setzen (hoher RAM-Bedarf), Deduplizierung läuft
+ausschließlich App-seitig über restic.
+
 ## Prüfungen
 
 ```bash