Kapitel 17a Compliance, Storage & Betrieb Admin: #/protect/overview

Sicherung & Wiederherstellung (nextxch Protect): Beweisexport, Konfiguration, Daten, Restore und Anbieterwechsel

nextxch Protect bündelt im Admin unter Sicherung & Wiederherstellung alles, was Sie für Nachweis, Sicherung und Wiederherstellung brauchen: beweissicherer EML-Export mit Ed25519-signiertem Manifest, Konfigurationssicherung mit Versionen, verschlüsselte inkrementelle Datensicherung (Verzeichnis, SMB-Freigabe oder S3 mit Object Lock), Wiederherstellung ins Postfach aus GoBD-Archiv, gelöschten Elementen oder Datensicherung, Bare-Metal-Recovery beim ersten Start sowie Ausrollen per Pipeline mit Restore und Live-Sync für den Anbieterwechsel. Alles ist im Server eingebaut, ohne Zusatzprodukt und ohne externen Dienst.

Praxis-Tipp & Architektur-Hinweis

Reihenfolge für den Start: zuerst unter Sicherung & Wiederherstellung > Konfiguration den Sicherungsschlüssel einrichten (Passphrase mit mindestens 12 Zeichen oder Wiederherstellungsschlüssel, nur als angemeldeter Server-Admin) und außerhalb des Servers aufbewahren. Konfigurations- und Datensicherung nutzen denselben Schlüssel; der Server speichert nur den öffentlichen Teil und kann Sicherungen schreiben, aber nie lesen. Lizenz: Konfigurationssicherung, Prüfung von Beweisexporten, Selbstbedienung im Webmail, Wiederherstellung beim ersten Start und Pipeline-Restore der Konfiguration sind in jeder Stufe enthalten; Datensicherung, Beweisexport, Wiederherstellungsaufträge, der Datenteil des Pipeline-Restores und der Live-Sync ab Business.

1. Schnellstart: Schlüssel, Ziel, erste Sicherung und Prüfung

Ziele und Zeitpläne richten Sie unter Sicherung & Wiederherstellung > Zeitpläne & Ziele ein (nur Server-Admins). nextxch-cli meldet sich mit einem API-Schlüssel oder einer Admin-Anmeldung an.

Referenz / Konfiguration

# 1. Admin > Sicherung & Wiederherstellung > Konfiguration: Sicherungsschlüssel einrichten
#    (Passphrase ab 12 Zeichen oder Wiederherstellungsschlüssel, sicher außerhalb des Servers ablegen)
# 2. Zeitpläne & Ziele: Ziel anlegen (Verzeichnis, SMB-Freigabe \\nas\backup\nextxch oder S3) und "Testen"
# 3. Konfiguration sichern (jede Stufe) und als Datei mitnehmen:
nextxch-cli config backup --label "vor Umstellung" -o nextxch-config.zip

# 4. Datensicherung (Business): voll, danach inkrementell per Zeitplan
nextxch-cli backup run --target nas --full
nextxch-cli backup list --target nas

# 5. Prüfen, mit Passphrase inklusive Entschlüsselung der Stichprobe
export NEXTXCH_BACKUP_PASSPHRASE='...'
nextxch-cli backup verify --target nas --passphrase-env NEXTXCH_BACKUP_PASSPHRASE --limit 200

2. Beweissicherer Export: ZIP, Manifest, Signatur und Prüfung

Nachrichten kommen byte-genau als .eml ins ZIP. manifest.json listet jede Datei mit SHA-256, Größe, Archiv-Hash, Integritätsstatus, Aufbewahrung und Legal Hold; manifest.json.sig ist eine Ed25519-Signatur über die exakten Bytes des Manifests, abgeleitet aus dem Server-Geheimnis und auf allen Cluster-Knoten gleich. Den öffentlichen Schlüssel liefert GET /api/compliance/exports/public-key ohne Anmeldung. Die Option decrypt entschlüsselt nur die Verschlüsselung im Ruhezustand (nur ServerAdmin und ComplianceAuditor, sonst 403 DECRYPT_NOT_ALLOWED); sie ist keine allgemeine S/MIME- oder OpenPGP-Entschlüsselung. Der Einzel-Download GET /api/compliance/messages/{id}/raw liefert die Hashes als HTTP-Header X-Nextxch-Sha256, X-Nextxch-Stored-Sha256, X-Nextxch-Integrity und Repr-Digest. Export ab Business, Prüfung in jeder Stufe.

Referenz / Konfiguration

nextxch-evidence-20261111-0930-1a2b3c4d.zip
  messages/000001-<archiveId>.eml     Original-Nachricht, byte-genau
  messages/000002-<archiveId>.eml
  SHA256SUMS.txt                      prüfbar mit sha256sum -c
  manifest.json                       format nextxch-evidence-export/1, scope (inkl. caseReference), items[]
  manifest.json.sig                   Ed25519: algorithm, keyId, publicKey, signedSha256, signature
  README.txt

# Export starten (202, Status unter GET /api/compliance/exports/{id}):
curl -X POST https://mail.firma.de/api/compliance/exports -H "X-Api-Key: $KEY" \
  -H "Content-Type: application/json" \
  -d '{"scope":"mailbox","account":"anna@firma.de","sinceUtc":"2026-01-01T00:00:00Z","caseReference":"AZ 4 O 123/26"}'

# Offline prüfen, ohne Zugriff auf den Server (Exit-Code 0 gültig, 1 ungültig/verändert, 2 Aufruffehler):
curl -s https://mail.firma.de/api/compliance/exports/public-key > nextxch-evidence-key.json
nextxch-cli export verify nextxch-evidence-20261111-0930-1a2b3c4d.zip --public-key <publicKey aus der Datei>
unzip -d export nextxch-evidence-20261111-0930-1a2b3c4d.zip && cd export && sha256sum -c SHA256SUMS.txt

3. Konfigurationssicherung: Inhalt, Verschlüsselung, Diff und teilweise Wiederherstellung

Ein Paket enthält die Konfiguration als Code (config/*.yaml), Zustandsdateien ohne Geheimnisse (server/*), Sieve-Regeln und die verschlüsselten Geheimnisse in secrets.enc (AES-256-GCM, Datenschlüssel für den Sicherungsschlüssel verpackt; eine manuelle Sicherung kann zusätzlich eine eigene Passphrase bekommen). Abschnitte: config:<bereich>, dkim, passwords, tls-certificates, api-keys, sieve, server-files, licence; licence, passwords und api-keys werden nur wiederhergestellt, wenn sie ausdrücklich genannt sind. Die Wiederherstellung ist standardmäßig ein Trockenlauf mit Vorschau. In jeder Stufe; REST unter /api/v1/config/backups.

Referenz / Konfiguration

nextxch-cli config list                                   # Versionen (Grund: manual, pre-update, after-change, pre-restore, import)
nextxch-cli config diff 20261101T020000Z-a1b2c3 current             # Unterschied zweier Versionen oder zum aktuellen Stand
nextxch-cli config backup --label "vor Update" --passphrase-env BACKUP_PW -o nextxch-config.zip
nextxch-cli config import -f nextxch-config.zip           # Paket eines anderen Servers übernehmen

# Teilweise Wiederherstellung: erst Vorschau, dann anwenden
nextxch-cli config restore 20261101T020000Z-a1b2c3 --sections dkim,config:domains --domain firma.de --dry-run
nextxch-cli config restore 20261101T020000Z-a1b2c3 --sections dkim,config:domains --domain firma.de --yes

# REST: POST /api/v1/config/backups/{id}/restore
# {"sections":["dkim","config:domains"],"domain":"firma.de","prune":false,"dryRun":true}

4. Datensicherung: Ziele, Format und Katalog

Jeder Lauf erzeugt eine eigenständige Version: Datenbank-Snapshot je Tabelle (anbieterneutral, so ist auch SQLite nach PostgreSQL möglich), Zustandsdateien, GoBD-Archiv-Manifest und alle referenzierten Blobs. Blobs sind nach SHA-256 adressiert und werden nur einmal übertragen; ein inkrementeller Lauf lädt nur neue Hashes hoch. Alles liegt verschlüsselt im NXB1-Format (AES-256-GCM in Blöcken, an den Objektnamen gebunden). Katalog und Blob-Index sind lesbares JSON ohne Geheimnisse, der Katalog ist mit dem Ed25519-Schlüssel des Beweisexports signiert. Das vollständige Format steht im Repository unter docs/protect/backup-format.md. Ab Business; REST unter /api/admin/protect/backups (Server-Admins).

Referenz / Konfiguration

<Ziel>/                                   Verzeichnis, SMB-Freigabe oder s3://bucket/nextxch-backup/
  nextxch-backup.json                       Zielmarkierung
  keys/backup-key-<keyId>.json              öffentlicher Schlüssel + versiegelter privater Schlüssel
  keys/dk-<dataKeyId>.json                  Datenschlüssel eines Laufs (ECDH verpackt)
  blobs/ab/cd/<sha256>.nxb                  eine Mail bzw. ein Dateiinhalt, unveränderlich
  versions/20261111T023000Z-a1b2c3/
    catalog.json  catalog.json.sig          Katalog (zuletzt geschrieben = Version vollständig) + Signatur
    blobs.ndjson.gz                         Blob-Index der Version
    db/<tabelle>.ndjson.gz.nxb              Datenbank-Snapshot, eine Datei je Tabelle
    files/<pfad>.nxb                        Zustandsdateien des Datenverzeichnisses
    archive-manifest.json.gz.nxb            Aufbewahrung, Legal Hold, Integritätskette

# Einstellungen per REST (PUT /api/admin/protect/backups/settings):
{"verifyEveryHours":24,"verifySampleSize":50,"alertOnFailure":true,"uploadParallelism":4}

# Domäne oder einzelne Postfächer sichern:
nextxch-cli backup run --target s3-fsn1 --scope domains:firma.de,firma.at
nextxch-cli backup run --target s3-fsn1 --scope mailboxes:anna@firma.de --no-wait

5. Wiederherstellung ins Postfach: Quelle, Zeitpunkt, Ziel

Quellen: archive (GoBD-Archiv), recoverable (gelöschte Elemente) und backup (Datensicherung). Den Zeitpunkt wählen Sie mit --point (Snapshot-Id, day:yyyy-MM-dd oder latest) oder --as-of. Ziele: original (Originalordner), restored (Standard, Ordner "Wiederhergestellt yyyy-MM-dd", Name per --label) oder account (ein anderes Postfach desselben Mandanten, z. B. ein Nachfolgerpostfach). Duplikate werden per SHA-256, Message-ID und UID übersprungen, die Quellen bleiben unverändert. Erlaubt für TenantAdmin und ServerAdmin, bis 250 000 Elemente je Auftrag; Aufträge ab Business, Richtlinie und Webmail-Selbstbedienung in jeder Stufe.

Referenz / Konfiguration

nextxch-cli restore points  --account anna@firma.de --source backup
nextxch-cli restore browse  --account anna@firma.de --source backup --point latest --folder INBOX --filter "Rechnung"
nextxch-cli restore preview --account anna@firma.de --source archive --as-of 2026-10-31T23:59:59Z --folder "Projekte/Neubau"
nextxch-cli restore start   --account anna@firma.de --source archive --as-of 2026-10-31T23:59:59Z \
  --folder "Projekte/Neubau" --target restored --label "Neubau (wiederhergestellt)"

# Ganzes Postfach in ein Nachfolgerpostfach:
nextxch-cli restore start --account ben@firma.de --source backup --point day:2026-11-01 \
  --target account --target-account nachfolger@firma.de --passphrase-env NEXTXCH_BACKUP_PASSPHRASE
nextxch-cli restore jobs --account ben@firma.de

# REST: /api/compliance/restore (sources, points, browse, preview, jobs, policy)
# Webmail: GET /api/mail/self-restore, POST /api/mail/self-restore {"ids":[...]}

6. Bare-Metal-Recovery: neue Installation plus Sicherung ergibt den alten Server

Auf einer frischen Installation (MSI, Docker oder Linux, höchstens ein Mandant, eine Domäne, ein Konto und noch keine Admin-Anmeldung) zeigt /setup/ unter der Anmeldung "Aus Backup wiederherstellen": Paket hochladen, Passphrase, Vorschau, Wiederherstellen, optional Datensicherung, Abschließen und Neustart. Zugriff nur mit dem einmaligen Einrichtungs-Token, das der erste Start ins Log und nach {DataDirectory}/first-run/setup-token.txt schreibt (Header X-Nextxch-Setup-Token), oder vom Server selbst mit Setup:TrustLoopback=true. Die erste Admin-Anmeldung oder Abschließen schließt den Assistenten endgültig. Der Sicherungsschlüssel des alten Servers wird nicht übernommen und ist danach neu einzurichten. Der SQLite-Volltextindex ist nicht Teil der Sicherung: die Suche findet wiederhergestellte Mails nach einer Neuindizierung.

Referenz / Konfiguration

# Headless per CLI (dieselbe API /api/setup):
export NEXTXCH_SETUP_TOKEN="$(cat /var/lib/nextxch/first-run/setup-token.txt)"
export NEXTXCH_BACKUP_PASSPHRASE='...'
nextxch-cli setup restore --config nextxch-config.zip --data s3://dr-bucket/nextxch/ --prune --dry-run
nextxch-cli setup restore --config nextxch-config.zip --data s3://dr-bucket/nextxch/ --prune --yes

# Unbeaufsichtigt beim ersten Start (Docker Compose, Kubernetes, MSI):
environment:
  NEXTXCH_RESTORE_FROM: s3://dr-bucket/nextxch/          # .zip, Verzeichnis, s3://, https:// oder config-backup:<id>
  NEXTXCH_RESTORE_PASSPHRASE: ${BACKUP_PASSPHRASE}       # ohne: Konfiguration ohne Geheimnisse
  NEXTXCH_RESTORE_DATA_FROM: s3://dr-bucket/nextxch/     # optional, Ort der Datensicherung
  NEXTXCH_RESTORE_PRUNE: "true"                          # Bootstrap-Objekte entfernen
  NEXTXCH_RESTORE_WITH_CREDENTIALS: "true"               # Passwörter, API-Schlüssel, Lizenz (Standard true)
  NEXTXCH_RESTORE_S3_ENDPOINT: https://fsn1.your-objectstorage.com
  NEXTXCH_RESTORE_S3_ACCESS_KEY: ${S3_KEY}
  NEXTXCH_RESTORE_S3_SECRET_KEY: ${S3_SECRET}
# Ergebnis: {DataDirectory}/pipeline-restore/first-start.json ("ok": true = Variable wird danach ignoriert)
# Helm: restore.from, restore.scope, restore.mapping, restore.passphrase, restore.s3.* (replicaCount: 1)

7. Ausrollen per Pipeline mit Restore (nextxch-cli deploy --restore)

Ein Befehl oder Pipeline-Schritt baut einen Server aus einer Sicherung neu auf: Konfiguration einspielen, Daten wiederherstellen, Prüflauf (Hash-Stichprobe, Health, Testmail nur an Mailpit oder ein lokales Postfach) und optional eine Anleitung für die DNS/MX-Umstellung; DNS wird nie automatisch geändert. Jeder Lauf ist idempotent und setzt nach einem Abbruch beim letzten fertigen Schritt fort. Die Mapping-Datei (kind RestoreMapping, Schema unter GET /api/v1/deploy/mapping-schema) schreibt Hostnamen, IP-Adressen und Pfade um, legt die Herkunft der Zertifikate fest (backup, acme, files) und beschreibt Datenbank und Speicher des neuen Hosts; Maildomänen werden nie umbenannt. Anmeldung mit einem Integrations-Schlüssel mit Scope deploy.restore. Konfiguration in jeder Stufe, Datenteil ab Business (außer beim ersten Start einer frischen Installation); der Datenteil umfasst den Umfang all.

Referenz / Konfiguration

# mapping.yaml
apiVersion: nextxch/v1
kind: RestoreMapping
hostnames:
  mail.alter-anbieter.example: mail.firma.de
ips:
  203.0.113.10: 198.51.100.20
paths:
  "C:\\Data\\NextxchData": /var/lib/nextxch
certificates:
  mode: acme                      # backup | acme | files
  acme: {contactEmail: hostmaster@firma.de}
database:
  provider: Postgres              # muss zum neuen Host passen (Storage__Provider)
  connectionStringEnv: NEXTXCH_PG_CONNECTION
storage:
  blobBackend: S3
  s3: {endpoint: https://fsn1.your-objectstorage.com, bucket: nextxch-mail}

# Plan (Trockenlauf, zeigt jede Ersetzung), dann Restore mit Prüflauf:
nextxch-cli deploy --restore ./nextxch-config.zip --scope config --map mapping.yaml --dry-run
nextxch-cli deploy --restore s3://dr-bucket/nextxch/ --map mapping.yaml --test-mail mailpit --dns-instructions --yes

# REST: POST /api/v1/deploy/restore (dryRun ist standardmäßig true)
# {"source":"s3://dr-bucket/nextxch/","scope":"all","mapping":"...","dryRun":false,"testMail":"mailpit","hashSample":20}
# Lokales Paket: POST /api/v1/deploy/restore/upload (application/zip) -> source "upload:<sha256>"
# Läufe: GET /api/v1/deploy/restore/runs

8. CI-Vorlagen: GitHub Actions, GitLab CI, Azure DevOps und Ansible

Die Vorlagen liegen im Repository unter deploy/ci: Restore mit Plan-Stufe und Freigabe auf der Umgebung production sowie eine nächtliche DR-Probe, die in eine Wegwerf-Umgebung wiederherstellt und einen Bericht mit Dauer (RTO) und Stand (RPO) schreibt. Geheimnisse gehören in maskierte, geschützte CI-Variablen; Testmails gehen an einen Mailpit-Container neben dem Job und verlassen ihn nie.

Referenz / Konfiguration

deploy/ci/github-actions/nextxch-restore.yml        Plan auf Wegwerf-Instanz, Container mit Restore beim ersten Start, Prüfungen, DNS-Schritt
deploy/ci/github-actions/nextxch-dr-probe.yml       nächtliche DR-Probe mit RTO/RPO-Bericht
deploy/ci/gitlab/.gitlab-ci.yml                     Restore (RESTORE_SOURCE, RESTORE_SCOPE, PLAN_ONLY ...) + DR-Probe (NEXTXCH_PIPELINE=dr-probe)
deploy/ci/azure-devops/azure-pipelines.yml          Restore mit Parametern, Deployment-Job auf Umgebung production
deploy/ci/azure-devops/azure-pipelines-dr-probe.yml nächtliche DR-Probe, Bericht in der Laufzusammenfassung
deploy/ci/ansible/playbook-restore.yml              Rolle nextxch_restore: Container (Linux) oder MSI (Windows)
deploy/ci/mapping.example.yaml, mapping.schema.json Beispiel und JSON Schema der Mapping-Datei

9. Live-Sync für den Anbieterwechsel: kurzes Einfrieren statt langer Auszeit

Nach dem vollständigen Restore folgt der neue Server dem alten mit Delta-Läufen: Der alte Server schreibt weiter seine Datensicherung (z. B. stündlich nach S3), jeder Lauf übernimmt nur Blobs, Tabellenzeilen und Zustandsdateien, die sich seit der zuletzt übernommenen Version geändert haben. Der Fortschritt steht in {DataDirectory}/pipeline-restore/live-sync.json; derselbe Befehl erneut ändert nichts oder setzt fort. Zur Umschaltung wird der alte Server von Hand eingefroren (Mail- und Client-Ports an seiner Firewall sperren, Dienst weiterlaufen lassen, letzte Sicherung mit nextxch-cli backup run --full), dann übernimmt --cutover --source-frozen diese Sicherung mit vollständigem Zeilenvergleich. Danach den neuen Server neu starten und DNS umstellen. Ab Business; REST: POST /api/v1/deploy/live-sync, POST /api/v1/deploy/live-sync/cutover, GET /api/v1/deploy/live-sync.

Referenz / Konfiguration

nextxch-cli deploy --restore s3://dr-bucket/nextxch/ --scope all --yes                          # 1. vollständiger Restore (Basis)
nextxch-cli deploy --restore s3://dr-bucket/nextxch/ --live-sync --dry-run                      # verbleibendes Delta, ändert nichts
nextxch-cli deploy --restore s3://dr-bucket/nextxch/ --live-sync --interval 5m --until-cutover  # 2. dem alten Server folgen
nextxch-cli deploy --restore s3://dr-bucket/nextxch/ --cutover                                  # 3. Anleitung zum Einfrieren
# alter Server: Ports sperren, dann  nextxch-cli backup run --full
nextxch-cli deploy --restore s3://dr-bucket/nextxch/ --cutover --source-frozen                  # 4. letzte Sicherung, letzter Lauf

Einstellungen, Standardwerte & Best Practices

Einstellung / Ort	Funktion	Standardwert	Best Practice im Betrieb
`Konfigurationssicherung: Versionen (#/protect/config)`	Automatische Versionen vor jedem Update (AutoBeforeUpdate) und nach Änderungen (AutoAfterChanges, gebündelt nach DebounceMinutes), dazu manuelle Versionen, Importe und ein Sicherheits-Snapshot vor jeder Wiederherstellung.	`KeepLast 30 · KeepDailyDays 90 · Debounce 10 min`	Vor größeren Umbauten eine manuelle Version mit Bezeichnung anlegen und als .zip außerhalb des Servers ablegen.
`Sicherungsschlüssel (Passphrase / Wiederherstellungsschlüssel)`	ECDH P-256; der private Teil liegt nur versiegelt vor (PBKDF2-SHA256 mit 600 000 Iterationen, AES-256-GCM) und reist in jedem Paket mit. Ohne Schlüssel und ohne Passphrase enthält eine Konfigurationssicherung keine Geheimnisse.	`nicht eingerichtet · Passphrase ab 12 Zeichen`	Wiederherstellungsschlüssel ausdrucken und getrennt vom Server verwahren; ohne ihn sind Datensicherungen nicht lesbar.
`Datensicherung: Aufbewahrung je Ziel`	Die neuesten KeepLast-Versionen plus die jeweils neueste Version der letzten KeepHourly Stunden, KeepDaily Tage, KeepWeekly ISO-Wochen und KeepMonthly Monate (UTC).	`3 / 24 / 7 / 4 / 12`	Während eines Live-Syncs mindestens zwei Versionen behalten, sonst lässt sich das Delta nicht berechnen (BASELINE_GONE).
`S3 Object Lock (ObjectLockMode, ObjectLockDays)`	Objekte werden mit Modus Governance oder Compliance und einer Sperrfrist geschrieben; wiederverwendete Blobs bekommen eine verlängerte Frist (jetzt plus 1,5-mal die Sperrtage), damit keine Version auf ein vorzeitig löschbares Objekt zeigt.	`Normal · 30 Tage`	Für Schutz vor Ransomware Compliance-Modus auf einem eigenen Bucket mit Versionierung verwenden; gesperrte Objekte entfernt erst ein späterer Lauf nach Ablauf.
`Zeitpläne (Frequency, Type, Scope)`	Stündlich, täglich oder wöchentlich, inkrementell oder voll, je Ziel und Umfang (Server, Domänen, Postfächer); Uhrzeit in Serverortszeit, kein Cron-Ausdruck.	`Täglich 02:30 inkr. · Sonntag 03:30 voll`	Die vorbereiteten Zeitpläne haben anfangs kein Ziel: Ziel zuweisen und aktivieren, sonst läuft keine Sicherung.
`Automatische Prüfung (VerifyEveryHours, VerifySampleSize)`	Prüft gespeicherte Hashes, Envelope-Header, Schlüsseldateien, Katalogsignatur und die Lesbarkeit von Katalog und Blob-Index ohne Schlüssel; mit Passphrase werden zusätzlich die Stichprobe und alle Tabellendateien entschlüsselt.	`alle 24 h · 50 Objekte`	AlertOnFailure eingeschaltet lassen, damit fehlgeschlagene Sicherungen und Prüfläufe an die Alarmziele gehen.
`Parallele Uploads je Sicherung (UploadParallelism)`	Anzahl gleichzeitiger Uploads zu S3- und Verzeichniszielen.	`4 (1 bis 32)`	Bei S3 über schnelle Leitungen 8 bis 16; bei einem NAS über langsames SMB eher 2 bis 4.
`SQL Server: ALLOW_SNAPSHOT_ISOLATION`	nextxch versucht beim Start, Snapshot-Isolation einzuschalten. Ist sie aus, wird Tabelle für Tabelle mit READ COMMITTED exportiert (consistency read-committed) und der Lauf meldet eine Warnung.	`an, wenn erlaubt`	Die Übersicht zeigt die SQL-Anweisung zum Kopieren; mit Snapshot-Isolation ist der Datenbank-Snapshot transaktionskonsistent.
`RecoverableItemsDays (restore-policy.json)`	Wie lange gelöschte Termine, Kontakte, Aufgaben und Notizen ihren Inhalt behalten; danach bleibt nur ein leerer Tombstone für die Synchronisation. Weich gelöschte Mails bleiben, bis sie endgültig entfernt werden.	`14 Tage (nach Upgrade 30)`	In der Verfahrensdokumentation vermerken: Ohne Datensicherung verlieren gelöschte Groupware-Elemente nach dieser Frist ihren Inhalt.
`Selbstbedienung im Webmail (SelfServiceEnabled, SelfServiceDays)`	Benutzer holen gelöschte Mails und Groupware-Elemente unter Gelöschte Elemente wiederherstellen selbst zurück (bis 500 je Lauf). Serverweit oder je Domain einstellbar; 0 Tage bedeutet kein eigenes Zeitfenster.	`an · 0 Tage`	Für Domains mit strengen Vorgaben ein Zeitfenster setzen oder die Selbstbedienung dort abschalten.
`Beweisexport: Rollen, Umfang, Download`	Exportieren dürfen ComplianceAuditor, TenantAdmin (nur eigener Mandant) und ServerAdmin; Umfang search, mailbox, range oder legalHold, bis 100 000 Nachrichten (höchstens 250 000). Der Download-Link gilt 24 Stunden.	`includeSoftDeleted true · 24 h`	Immer ein Aktenzeichen (caseReference) angeben: Es steht im signierten Manifest und im Audit-Log.
`Setup:TrustLoopback`	Erlaubt Anfragen vom Server selbst (Loopback) an den Einrichtungsassistenten ohne Einrichtungs-Token. Standardmäßig braucht jede Anfrage das Token aus first-run/setup-token.txt.	`false`	Nur auf Hosts ohne weitere lokale Benutzer setzen; sonst das Token per NEXTXCH_SETUP_TOKEN übergeben.
`Audit-Log & GoBD`	Jeder Schritt steht im Audit-Log: config.backup, data.backup., Compliance.EvidenceExport, Protect.Restore, Protect.SelfRestore, Protect.RestorePolicy, setup.* und config.restore; sichtbar unter Sicherung & Wiederherstellung > Protokoll. Das GoBD-Archiv bleibt bei jeder Wiederherstellung unverändert.	`aktiv`	Die Datensicherung enthält das Archiv-Manifest mit Aufbewahrung und Legal Hold; nach einer Wiederherstellung werden alle archivierten Hashes geprüft und die Sperren erneut gesetzt.