archivmail/features/PROJ-66-backup-strategie.md

PROJ-66: Backup-Strategie für archivmail (Produktiv + Teilproduktiv)

Status: Planned Erstellt: 2026-07-04

Problem / Ausgangslage

Nachtrag (2026-07-04, nach Nutzer-Rückmeldung): Auf Infrastruktur-Ebene existiert bereits eine Sicherung: Die Container werden per Snapshot auf einen zweiten Server synchronisiert und zusätzlich per Proxmox Backup Server (PBS) gezogen. Das ist von innerhalb des Containers nicht sichtbar (läuft vom Proxmox-Host aus) — deshalb kam die ursprüngliche Prüfung unten ("kein Backup-Prozess") zu einem unvollständigen Bild. Das entschärft die zuvor als Blocker geführte Frage nach einem Off-Site-Ziel erheblich: PBS + Sync auf zweiten Server ist bereits eine physisch getrennte Sicherung.

Was das ändert und was offen bleibt, siehe Abschnitt "Bewertung der Infra-Ebene" weiter unten. Der ursprüngliche Befund (App-Ebene: kein pg_dump/rsync/Cron für archivmail selbst) bleibt als Kontext stehen, ist aber durch die Infra-Sicherung teilweise bereits abgedeckt.

Verifizierter Ist-Stand (geprüft am 2026-07-04, beide Hosts)

Beide Server sind LXC-Container (systemd-detect-virt → lxc), das zugrunde liegende Storage ist ein ZFS-Dataset auf dem Proxmox-Host (zfs/data/subvol-1131-disk-0 bzw. -1132-disk-0), aber aus dem Container heraus nicht als ZFS ansprechbar (kein zfs/zpool-Binary im Container, kein Zugriff auf Host-Snapshots). Zff-Snapshots wären nur vom Proxmox-Host aus möglich — das ist eine separate Maßnahme außerhalb der Kontrolle des archivmail-Deploy-Prozesses und wird hier als Zusatzoption erwähnt, aber nicht als alleinige Lösung behandelt (siehe Optionen unten).

Geprüft und nicht vorhanden:

• crontab -l (root): leer auf beiden Hosts
• /etc/cron.d/: nur archivmail (App-eigener Cron, PROJ-56c Purge/Reindex/OCR), e2scrub_all, sysstat — kein Backup-Eintrag
• /etc/cron.{daily,hourly,weekly}: nur Standard-Debian-Pakete (apt, dpkg, logrotate, man-db) — kein Backup-Skript
• systemctl list-timers: nur Standard-systemd/apt-Timer, kein Backup-Timer
• LVM: kein lvs/vgs im Container
• Borg/Restic/rsnapshot/Bacula: nicht installiert
• /var/backups/: enthält nur dpkg/apt-Housekeeping-Dateien, keine archivmail-Daten

Vorhanden, aber ungenutzt/nicht automatisiert:

• pg_basebackup, pg_backupcluster (Debian-PostgreSQL-Standardtools) — installiert, aber kein Aufruf irgendwo
• manticore-backup — installiert, kein Aufruf irgendwo

Fazit: Bei Totalausfall eines der beiden Container (Hardware, Filesystem- Korruption, versehentliches rm, Ransomware, fehlerhaftes Update) sind Store, Keyfile und Datenbank unwiederbringlich verloren. Das betrifft aktuell sowohl 131 (Produktiv) als auch 132 (teilproduktiv, ~51.000 Mails).

Aktuelle Datenmengen (Referenz für Aufwandsschätzung)

Server	Store-Größe	DB	Config
131	3,8 MB (frisch, PROJ-65-Migration)	n/a (Verbindungsproblem bei Check — Peer-Auth)	23 KB
132	6,9 GB (~51.000 Mails)	n/a (nicht separat geprüft)	—

Store-Wachstum ist also unterschiedlich weit fortgeschritten; 132 hat den größeren produktiven Datenbestand trotz "Test"-Label.

Bewertung der Infra-Ebene (PBS + Server-Sync)

Container-/Snapshot-Backup auf Proxmox-Ebene sichert typischerweise das komplette Root-Filesystem des LXC — d.h. /var/archivmail/store, /etc/archivmail/keyfile, /etc/archivmail/config.yml, PostgreSQL-Datendir und /var/log/archivmail/audit.log gemeinsam als ein Snapshot. Das löst das in "Warum das kritisch ist" beschriebene Kern-Risiko (Store/Keyfile/DB müssen zusammen gesichert werden) potenziell bereits vollständig, da alles im selben Container liegt und in einem Snapshot landet — vorausgesetzt PostgreSQL läuft ebenfalls im selben Container wie Store/Keyfile (zu verifizieren, siehe offene Punkte unten).

Was dadurch (voraussichtlich) bereits erfüllt ist:

• Physische Trennung (AC 3) — zweiter Server + PBS sind eigene Infrastruktur.
• Gemeinsame Konsistenz von Store+DB+Keyfile+Config (AC 1) — ein Filesystem-Snapshot enthält zwangsläufig alle Dateien vom selben Zeitpunkt.
• Hardlink-Erhalt (AC 2) — ein Block-/Filesystem-Snapshot (ZFS/PBS) kopiert keine Dateien einzeln, sondern sichert die Filesystem-Struktur inklusive Inode-Referenzen — Hardlinks aus PROJ-65 bleiben dabei erhalten (anders als bei einem naiven cp -r, das dieses Ticket ursprünglich als Risiko für ein noch zu bauendes App-Backup benannt hatte).

Was weiterhin offen bleibt, auch mit PBS+Sync:

1. PostgreSQL-Crash-Konsistenz: Ein Snapshot mitten im Betrieb ist für PostgreSQL kein sauberes Backup wie pg_dump, sondern entspricht einem Stromausfall-Szenario — PostgreSQL kommt damit über WAL-Replay beim nächsten Start i.d.R. wieder in einen konsistenten Zustand (das ist der Normalfall, für den WAL gebaut ist), aber das ist nicht dasselbe wie ein verifizierter, anwendungskonsistenter Dump. Sollte einmal getestet werden (Restore-Test, siehe unten), nicht nur angenommen.
2. Restore ist ungetestet — ein Backup, das nie zurückgespielt wurde, ist nicht verifiziert (gilt für PBS-Snapshots genauso wie für ein selbstgebautes rsync-Skript). Das ist unabhängig davon, wer das Backup zieht, weiterhin ein offener Punkt.
3. Retention/DSGVO-Abgleich: Wie lange hält PBS die Snapshots vor, und ist das mit der DSGVO-Löschkonzeption (PROJ-50) abgestimmt? Muss geklärt werden, ist aber eine reine Konfigurationsfrage im PBS, kein neuer Code.
4. Monitoring/Alerting: Läuft der PBS-Job zuverlässig durch, und gibt es eine sichtbare Warnung bei Ausfall? (Vermutlich ja, PBS hat eigenes Job-Monitoring — zu verifizieren, nicht Teil des archivmail-Codes.)
5. Keyfile-Einzelkopie (Bitwarden): Zusätzlich zur PBS-Sicherung soll das Keyfile separat in Bitwarden hinterlegt werden (Nutzer-Entscheidung, 2026-07-04) — als unabhängiger Wiederherstellungsweg, falls PBS/Snapshot- Infrastruktur selbst nicht verfügbar ist. Details siehe eigener Abschnitt unten.

Auswirkung auf den Rest dieser Spec: Die unten stehenden Optionen A/B/C und der App-eigene rsync+cron-Ansatz sind jetzt Ergänzung, nicht mehr alleinige Lösung — vor allem für den Fall, dass ein anwendungskonsistenter pg_dump zusätzlich zur PBS-Snapshot-Sicherung gewünscht wird (schnellerer, selektiver Restore einzelner Tabellen, unabhängig von Snapshot-Zeitpunkten). Die kritischste verbleibende Lücke ist nicht mehr "kein Backup-Ziel", sondern "Restore nie getestet" — das bleibt so oder so zu tun, egal welche Backup-Quelle (PBS oder App-Skript) im Ernstfall genutzt wird.

Warum das kritisch ist

1. Datenverlust ohne Backup ist bei einem Mail-Archivsystem ein Compliance-Vorfall, nicht nur ein IT-Vorfall — GoBD verlangt Verfügbarkeit archivierter Mails über die Aufbewahrungsfrist.
2. Store, Keyfile und PostgreSQL-Metadaten sind nur gemeinsam nutzbar:
   • Store ohne DB-Metadaten: Dateien vorhanden, aber keine Zuordnung zu Mail/Tenant/Betreff/Datum → praktisch nicht auffindbar.
   • Keyfile ohne Store: irrelevant, nichts zu entschlüsseln.
   • DB ohne Keyfile: Metadaten vorhanden, aber Mail-Inhalte nicht mehr entschlüsselbar → GoBD-Anforderung "Lesbarmachung" verletzt.
   • Ein Backup, das nur eine dieser drei Komponenten sichert, ist wertlos.
3. PROJ-65 hat gerade Tenant-Hardlink-Verzeichnisse (store/tenant_<id>/) eingeführt. Ein Backup-Tool, das Hardlinks nicht erhält (z.B. cp -r, naives scp -r), würde bei jedem Backup den Speicherbedarf im Backup-Ziel vervielfachen (pro Tenant eine Vollkopie statt eines Hardlinks) — kein Datenverlust, aber Speicherplatz-Explosion und potenziell Backup-Jobs, die wegen vollem Zielverzeichnis fehlschlagen.

Backup-Strategie-Optionen

Option A — rsync + cron, konsistenter Snapshot via kurzem Stop (empfohlen als erster Schritt)

Ablauf pro Lauf (nachts, Zeitfenster mit wenig Traffic wählen, ggf. an PROJ-56-Last-Entzerrung orientieren):

1. systemctl stop archivmail (Backend stoppen — Store/DB werden während des Kopiervorgangs nicht verändert; Frontend kann laufen bleiben, da es nur liest, aber optional auch stoppen für saubere Konsistenz)
2. pg_dump -Fc archivmail > backup.dump (Custom-Format, komprimiert, erlaubt selektiven Restore einzelner Tabellen)
3. rsync -aH --delete /var/archivmail/store/ <ziel>/store/ — -H ist Pflicht, sonst werden Tenant-Hardlinks aus PROJ-65 zu Vollkopien aufgelöst
4. cp /etc/archivmail/keyfile <ziel>/keyfile (getrennt verschlüsselt/ abgesichert, siehe unten)
5. cp /etc/archivmail/config.yml <ziel>/config.yml
6. cp /var/log/archivmail/audit.log <ziel>/audit.log.$(date +%F) (Append- Only-Charakter erhalten — Datei nicht überschreiben, sondern datiert kopieren, damit historische Audit-Nachweise auch bei Log-Rotation auf dem Quellsystem nicht verloren gehen)
7. systemctl start archivmail
8. Health-Check nach Neustart (Backend ✓ läuft, wie im Standard-Deploy-Workflow)
9. Manticore-Index: niedrige Priorität, aus Store+DB per archivmail reindex rekonstruierbar — kein Backup nötig, ggf. optional manticore-backup für schnelleren Recovery-Pfad (Reindex von 51k Mails kann je nach OCR-Last dauern)

Vorteil: Downtime ist kurz (Stop → Kopieren der geänderten Blöcke via rsync inkrementell → Start), einfach zu verstehen, kein neues Tooling nötig außer rsync/cron (beide bereits vorhanden). Nachteil: Downtime existiert (wenn auch kurz bei inkrementellem rsync nach dem ersten vollen Lauf).

Option B — PITR / kontinuierliche Konsistenz ohne Stop (vollständige Lösung, später)

• PostgreSQL: WAL-Archiving + Basisbackup (pg_basebackup) für Point-in-Time-Recovery statt Downtime beim Dump.
• Store: Da Store append-only/content-adressiert ist (Dateien werden nach Schreiben nie verändert, nur neue hinzugefügt oder per GoBD-Purge gelöscht), ist ein Live-rsync ohne Stop grundsätzlich risikoarm — die einzige Inkonsistenz-Gefahr ist ein Mail-Datensatz, der in der DB bereits committed ist, aber dessen Store-Datei noch nicht vollständig geschrieben wurde (Race zwischen Storage-Write und DB-Commit). Das lässt sich durch Reihenfolge Store-zuerst-dann-DB im Schreibpfad (falls nicht schon so implementiert — bei mailarchiv-architect erfragen) und/oder einen Reconciliation-Check nach dem Restore (PROJ-52 archivmail reconcile) abfedern statt durch Downtime.
• Aufwand deutlich höher (WAL-Archiv-Ziel, Retention der WAL-Segmente, mehr bewegliche Teile) — als Phase 2 vorschlagen, nicht als ersten Schritt.

Option C — Proxmox-Host-Snapshots (ZFS)

Da beide Hosts LXC-Container auf Proxmox mit ZFS-Backing sind, sind Host-seitige ZFS-Snapshots oder Proxmox-Backup-Server-Jobs eine sinnvolle Ergänzung (schnelle Rollback-Möglichkeit bei OS-/Config-Fehlern), aber kein Ersatz für anwendungskonsistente Backups: Ein ZFS-Snapshot mitten im pg_dump-losen Normalbetrieb sichert PostgreSQL nicht transaktionskonsistent (außer Postgres nutzt selbst WAL + fsync korrekt, was bei ZFS-Snapshots auf Blockebene in der Praxis meist funktioniert, aber nicht ausdrücklich validiert wurde). Empfehlung: als Zusatzschicht einplanen, aber erfordert Zugriff auf den Proxmox-Host, der nicht Teil dieses Deploy-Agenten-Scopes ist — separates Ticket/Absprache mit dem Infrastruktur-Verantwortlichen für den Proxmox-Host nötig.

Empfehlung

Phase 1 (dieses Ticket, pragmatisch): Option A — rsync+cron mit kurzem Stop, tägliches Backup auf ein Off-Container-Ziel (siehe Off-Site unten). Deckt das eigentliche Risiko (Totalverlust ohne jegliches Backup) sofort ab.

Phase 2 (späteres Ticket): Option B (PITR) wenn Downtime-Fenster zum Problem wird (z.B. wegen wachsendem Store auf 132), plus Option C als zusätzliche Sicherheitsschicht in Absprache mit Proxmox-Host-Admin.

Backup-Ziel: On-Site vs. Off-Site

• On-Site-only ist nicht ausreichend: Beide Produktivsysteme (131, 132) laufen vermutlich auf derselben Proxmox-Host-Infrastruktur — ein Host-Ausfall (Hardware, Ransomware, Fehlkonfiguration) könnte beide Systeme UND ein On-Site-Backup-Ziel gleichzeitig treffen, wenn es auf demselben Host/Storage liegt.
• Empfehlung: Backup-Ziel auf physisch getrennter Infrastruktur (zweiter Host, NAS außerhalb des Proxmox-Clusters, oder Cloud-Storage mit Verschlüsselung — Cloud nur wenn DSGVO-konform vertraglich abgesichert, siehe Verschlüsselung unten).
• Mindestens: 3-2-1-Prinzip anstreben (3 Kopien, 2 verschiedene Medien, 1 Off-Site) — für den pragmatischen ersten Schritt reicht 2 Kopien (Produktiv
  • 1 Backup-Ziel off-site) mit klarer Dokumentation, dass das noch nicht vollständig 3-2-1 ist.

Verschlüsselung des Backups selbst

Das Backup enthält Keyfile UND verschlüsselte Mails zusammen — sobald beide am selben Ort liegen, ist der Verschlüsselungsschutz des Stores faktisch aufgehoben, wenn das Backup-Ziel kompromittiert wird. Anforderungen:

1. Transport: rsync über SSH (ohnehin Standard) oder explizit rsync -e ssh, niemals unverschlüsseltes Protokoll (FTP, unverschlüsseltes NFS über öffentliches Netz).
2. At-Rest am Backup-Ziel: Wenn das Backup-Ziel als weniger vertrauenswürdig gilt als der Produktivserver (z.B. NAS mit mehr Admin-Zugriffsberechtigten, Cloud-Storage), muss das Backup-Ziel selbst verschlüsselt sein — entweder Ziel-Filesystem-Verschlüsselung (LUKS) oder Backup-Tool mit eingebauter Verschlüsselung (z.B. restic mit Repository-Passwort — als Phase-2-Option evaluieren, da es außerdem Deduplizierung/Versionierung mitbringt).
3. Keyfile separat behandeln: Empfehlung, das Keyfile-Backup zusätzlich getrennt vom Store-Backup aufzubewahren (anderer Zugriffspfad/anderes Passwort) — erschwert Angreifern, die nur das Backup-Ziel kompromittieren, den vollen Zugriff. Mindestens: restriktive Dateirechte (0600, root-only) auch im Backup.
4. Backup-Skript selbst darf Zugangsdaten (SSH-Key fürs Backup-Ziel) nicht im Klartext in world-readable Cron-Dateien ablegen (analog zu PROJ-64 Datei-Permissions-Härtung).

Keyfile-Escrow in Bitwarden (Nutzer-Entscheidung, 2026-07-04)

Zusätzlich zur PBS-/Sync-Sicherung wird das Keyfile als unabhängige Kopie in Bitwarden hinterlegt — für den Fall, dass die Snapshot-/PBS-Infrastruktur selbst nicht verfügbar oder kompromittiert ist.

• Zugriffsbeschränkung: Eigene Bitwarden-Collection/Ordner, nur für Personen mit Restore-Berechtigung sichtbar — nicht die allgemeine Organisations-Vault. Das Keyfile entschlüsselt das gesamte Archiv aller Mandanten, ist der höchstwertige Secret im System.
• Format: Secure Note mit Base64-kodiertem Keyfile-Inhalt (32 Byte roh → base64 fürs Notizfeld), plus Metadaten (welcher Server/welche Installation, Erstellungsdatum, wer hat's zuletzt geprüft).
• Kein Ersatz für Zugriffskontrolle: Bitwarden-Zugriff muss genauso ernst genommen werden wie root-Zugriff auf den Produktivserver (2FA Pflicht, Zugriffsprotokoll wenn Bitwarden das bietet).
• Rotation/Prüfung dokumentieren: Wer Zugriff hat und wann zuletzt verifiziert wurde, dass der Bitwarden-Eintrag noch mit dem aktiven Keyfile übereinstimmt (relevant falls das Keyfile jemals rotiert wird — aktuell nicht vorgesehen, aber für die Zukunft dokumentieren).
• Kein Blocker für die restlichen ACs — unabhängig von PBS/App-Backup umsetzbar, kleiner Zusatzschritt (Bitwarden-Eintrag anlegen, kein Code).

Aufbewahrungsdauer / Rotation

• Vorschlag: Tägliche Backups, Rotation nach Generationen-Prinzip:
  • 7 tägliche Backups
  • 4 wöchentliche Backups (z.B. jeweils Sonntag)
  • 6 monatliche Backups
• Wichtig: Rotation der Backup-Kopien ist unabhängig von der GoBD-Aufbewahrungsfrist der Mails selbst (PROJ-51 Retention-Kategorien) — eine gelöschte/abgelaufene Mail in Produktion kann in einem älteren Backup noch enthalten sein. Das ist im Rahmen der GoBD-Löschkonzeption (PROJ-50, DSGVO-Löschersuchen) zu dokumentieren: Backups mit personenbezogenen Daten, die in Produktion bereits DSGVO-gelöscht wurden, dürfen nicht unbegrenzt aufbewahrt werden → Backup-Rotation muss kurz genug sein, dass gelöschte Daten nach spätestens N Rotationszyklen auch aus alten Backups verschwinden (Abstimmung mit Datenschutzbeauftragtem/Nutzer nötig, kein rein technisches Thema).

Restore-Prozess (muss dokumentiert UND getestet sein)

Kein Backup ohne verifizierten Restore-Prozess. Vorschlag Runbook-Struktur (Stil analog docs/MIGRATION_RUNBOOK.md):

1. Zielserver vorbereiten (frisches Debian oder vorhandener Server im Wartungsmodus, archivmail-Dienste gestoppt).
2. Store wiederherstellen: rsync -aH <backup>/store/ /var/archivmail/store/ (Hardlinks bleiben erhalten).
3. Keyfile wiederherstellen: cp <backup>/keyfile /etc/archivmail/keyfile, Rechte prüfen (0600, root:root).
4. Config wiederherstellen: cp <backup>/config.yml /etc/archivmail/config.yml.
5. PostgreSQL wiederherstellen: pg_restore -d archivmail <backup>/backup.dump (auf leere, frisch angelegte DB).
6. Audit-Log wiederherstellen (informativ, kein Funktionsbestandteil): /var/log/archivmail/audit.log aus dem letzten Backup-Stand kopieren.
7. Dienste starten, Health-Check (Backend ✓, Frontend ✓ wie im Standard-Deploy-Workflow).
8. Verifikation (Pflicht, nicht optional):
   • archivmail reconcile laufen lassen (PROJ-52) — Zählvergleich Store-Dateien vs. DB-Einträge muss aufgehen.
   • Stichprobe: 3-5 zufällige Mails über die UI öffnen und lesbar entschlüsseln lassen (beweist Keyfile+Store+DB passen zusammen).
   • archivmail reindex ausführen, Suche testen (Manticore wird aus 1+3 rekonstruiert).
9. Restore-Ergebnis (Mail-Zahl, Zeitstempel, Dauer) dokumentieren — analog zum Migrations-Runbook-Prinzip "Zählen, Prüfen, Belegen".

Regelmäßiger Restore-Test: Ein Backup, das nie zurückgespielt wurde, ist nicht verifiziert. Empfehlung: mindestens vierteljährlich einen Restore auf einen isolierten Test-Container durchführen (nicht auf 131/132!) und Schritt 8 durchlaufen.

Monitoring / Alerting für den Backup-Job selbst

Größtes Risiko bei Cron-Backups: Job schlägt still fehl, niemand merkt es, bis der Ernstfall eintritt (siehe PROJ-58-Lehre: "Cron-Zeilen fehlten wochenlang trotz aktivem Code, weil es niemand automatisch prüfte").

Anforderungen:

• Backup-Skript muss Exit-Code aller Teilschritte prüfen (rsync, pg_dump, cp) und bei Fehler nicht die Rotation der alten (guten) Backups anstoßen (sonst wird ein gutes altes Backup durch ein fehlgeschlagenes überschrieben).
• Log-Datei pro Lauf mit Zeitstempel, Ergebnis, Dauer, Größe.
• Alerting: minimal ein "Backup-Alter"-Check, der z.B. vom bestehenden Health-Check-Mechanismus oder Dashboard (PROJ-17-Metriken-Anlehnung) mitgeprüft wird — "letztes erfolgreiches Backup älter als 26h" → sichtbarer Warnzustand (Dashboard-Badge oder E-Mail/Webhook, je nachdem was im System bereits an Alerting existiert; falls nichts existiert, ist das ein Teil dieses Tickets: minimal ein Cron-Check-Skript, das eine Markerdatei mit Zeitstempel nach erfolgreichem Lauf schreibt und ein zweiter Cron-Job/Health-Endpoint das Alter dieser Datei prüft).

User Stories

• Als Betreiber möchte ich, dass Store, Keyfile und DB-Metadaten täglich automatisiert und konsistent gesichert werden, damit ein Server-Totalausfall nicht zu unwiederbringlichem Mail-Verlust führt.
• Als Betreiber möchte ich, dass ein fehlgeschlagener Backup-Lauf sichtbar wird (nicht erst beim Restore-Versuch auffällt), damit ich rechtzeitig eingreifen kann.
• Als GoBD-Verantwortlicher möchte ich, dass ich im Audit-Fall belegen kann, dass Backups vorhanden, aktuell und restorebar sind.
• Als Datenschutzbeauftragter möchte ich, dass DSGVO-Löschungen (PROJ-50) nicht durch unbegrenzt aufbewahrte Backups unterlaufen werden.

Acceptance Criteria

1. Es existiert ein dokumentiertes, automatisiert laufendes Backup (Cron oder systemd-Timer) auf 131 UND 132, das Store, Keyfile, PostgreSQL-DB und config.yml konsistent zueinander sichert.
2. Das Backup-Tool erhält nachweislich Hardlinks im Store (Test: Backup-Größe nach PROJ-65-Tenant-Hardlinks entspricht nicht der Summe aller Tenant-Kopien, sondern der tatsächlichen Store-Größe — Stichprobe via du --apparent-size vs. du bzw. stat Link-Count-Check nach Restore).
3. Backup liegt auf einem vom Produktivsystem physisch getrennten Ziel (nicht im selben Proxmox-Host/-Storage wie 131/132, sofern das ohne zusätzliche Host-Beschaffung machbar ist — sonst als bekannte Einschränkung dokumentieren).
4. Backup-Daten (insbesondere Keyfile-Kopie und Store-Kopie zusammen) sind am Zielort verschlüsselt oder das Ziel ist gleichwertig abgesichert wie der Produktivserver.
5. Rotation/Retention ist implementiert und lässt Backups nicht unbegrenzt wachsen; Retention ist kurz genug, um DSGVO-Löschungen nicht dauerhaft zu unterlaufen (Zeitraum mit Nutzer/Datenschutzbeauftragtem abgestimmt).
6. Ein vollständiger Restore wurde mindestens einmal auf einem isolierten Testsystem durchgeführt und mit archivmail reconcile + Stichproben- Entschlüsselung verifiziert; Ergebnis ist dokumentiert.
7. Es gibt einen sichtbaren Alarm-/Warnmechanismus, wenn der letzte erfolgreiche Backup-Lauf älter als ein definiertes Schwellenwert-Fenster ist (z.B. 26h bei täglichem Backup).
8. Ein Backup-Runbook (analog docs/MIGRATION_RUNBOOK.md) existiert unter docs/BACKUP_RESTORE_RUNBOOK.md mit Schritt-für-Schritt-Anleitung für Backup, Restore und Verifikation.
9. update.sh-Vollständigkeits-Check: Falls das Backup-Skript/der Cron-Job als Datei unter deploy/ im Repo gepflegt wird, synct update.sh diese Datei nachweislich mit aus (Lehre aus PROJ-58, siehe Deploy-Vollständigkeits- Check in den devops-deploy-Regeln) — sonst existiert das Skript nur lokal und geht beim nächsten Server-Neuaufsatz verloren.
10. Keyfile-Kopie liegt zugriffsbeschränkt in Bitwarden (Secure Note, eigene Collection, nur Restore-Berechtigte) — unabhängig von PBS/App-Backup.
11. PBS-/Sync-Sicherung verifiziert: Dokumentiert ist, was genau gesichert wird (welcher Container/welche Pfade), wie lange PBS die Snapshots vorhält, und dass mindestens ein Restore aus einem PBS-Snapshot erfolgreich getestet wurde (nicht nur aus einem App-eigenen Backup, falls beide existieren).

Edge Cases

• Server-Totalausfall (131 oder 132): Restore auf neuem/wiederhergestelltem Container muss laut Runbook in angemessener Zeit möglich sein (Ziel-RTO definieren, z.B. < 4h für 132 mit 51k Mails — abhängig von Reindex-Dauer).
• Backup-Job schlägt fehl, ohne dass es auffällt: durch Monitoring/ Alerting (siehe oben) abgedeckt — Testfall: Backup-Skript künstlich zum Scheitern bringen (z.B. Zielverzeichnis vollschreiben) und prüfen, ob der Alarm tatsächlich auslöst.
• Restore-Test schlägt fehl: Reconcile zeigt Lücken → Ursache muss vor Produktivnutzung des Backups geklärt werden (z.B. Backup lief während aktiven Schreibvorgangs ohne Stop-Schritt → Konsistenzproblem im Backup-Skript selbst beheben).
• Backup-Ziel läuft voll: Rotation muss dies verhindern; zusätzlich Disk-Space-Check vor jedem Lauf (analog df -h-Diagnose-Befehl im devops-deploy-Skill) mit Abbruch + Alarm statt partiellem/korruptem Backup.
• PROJ-65-Hardlinks nach Restore: Nach Restore prüfen, dass Tenant-Hardlink-Struktur (store/tenant_<id>/) wiederhergestellt ist und nicht zu doppeltem Speicherverbrauch auf dem Zielsystem führt.
• Gleichzeitiger Schreibzugriff während Backup (Option A mit Stop): Kurzer Downtime-Fenster einplanen und in Betriebszeiten kommunizieren (SMTP- Empfang während Stop puffert sich ggf. beim Absender/Relay, sollte mit mailarchiv-architect abgeklärt werden, ob eingehende Mails während Backend- Stop verloren gehen könnten oder ob es einen Retry-Mechanismus gibt).
• 132 ist "teilproduktiv": Muss von Anfang an mit derselben Priorität wie 131 behandelt werden, nicht nachrangig als "nur Testserver" — bereits im Ticket-Titel und in den ACs berücksichtigt (beide Server, nicht nur 131).

Aufwandseinschätzung

Durch die vorhandene PBS+Sync-Infrastruktur verschiebt sich der Schwerpunkt von "Backup-Ziel schaffen" zu "vorhandenes Backup verifizieren + gezielt ergänzen":

• Phase 0 (klein, zuerst): Bitwarden-Keyfile-Escrow anlegen (kein Code, <1h). Dokumentieren, was PBS/Sync konkret sichert und mit welcher Retention (Abstimmung mit demjenigen, der PBS betreibt — vermutlich kein archivmail-Code-Zugriff nötig, eher ein Gespräch/Screenshot der PBS-Job-Konfiguration). Geschätzt 1-2h.
• Phase 1 (Restore-Verifikation, wichtigster verbleibender Schritt): Ein echter Restore-Test aus einem PBS-Snapshot auf einen isolierten Test-Container, durchlaufen mit archivmail reconcile + Stichproben- Entschlüsselung (siehe Restore-Prozess oben). Deckt auf, ob die PostgreSQL-Crash-Konsistenz in der Praxis reicht oder ob doch ein zusätzlicher pg_dump nötig ist. Geschätzt 2-4h (abhängig davon, wie schnell ein Testsystem für den Restore verfügbar ist).
• Phase 2 (nur falls Phase 1 Lücken zeigt): App-eigenes rsync+cron+pg_dump (Option A) als Ergänzung, falls PBS-Snapshots allein nicht ausreichen (z.B. weil Retention zu kurz für Compliance ist, oder PITR-Granularität gebraucht wird). Aufwand wie ursprünglich geschätzt, 4-6h.
• Phase 3 (optional, später): PITR/WAL-Archiving, restic/borg-Migration — nur falls Phase 1/2 einen konkreten Bedarf dafür aufzeigen.

Offene Entscheidung vor Implementierung von Phase 1: Steht ein isolierter Test-Container für den Restore-Test zur Verfügung (nicht 131/132 selbst)?

Nicht Teil dieses Tickets

• Implementierung selbst (dieses Ticket liefert nur die Spec, Status "Planned" — Implementierung erst nach Freigabe).
• Konfiguration/Änderung der PBS-Jobs selbst (liegt außerhalb des archivmail-Deploy-Scopes, eigener Verantwortungsbereich).
• Proxmox-Host-seitige ZFS-Snapshot-Konfiguration (separates Thema, anderer Verantwortungsbereich/Zugriff).