Capitolo 17a Conformità, storage & operatività Admin: #/protect/overview

Backup e ripristino (nextxch Protect): esportazione probatoria, configurazione, dati, ripristino e cambio di provider

nextxch Protect riunisce nell'admin, sotto Backup e ripristino, tutto ciò che serve per prove, backup e ripristino: esportazione EML con valore probatorio e manifesto firmato Ed25519, backup della configurazione con versioni, backup dei dati incrementale e crittografato (directory, condivisione SMB o S3 con Object Lock), ripristino nella casella di posta dall'archivio GoBD, dagli elementi eliminati o da un backup dei dati, ripristino bare-metal al primo avvio e deployment tramite pipeline con ripristino più sincronizzazione live per il cambio di provider. Tutto è integrato nel server, senza prodotti aggiuntivi e senza servizi esterni.

Suggerimento operativo & nota sull'architettura

Ordine per iniziare: configuri prima la chiave di backup in Backup e ripristino > Configurazione (una passphrase di almeno 12 caratteri o una chiave di ripristino, solo come amministratore del server con accesso effettuato) e la conservi fuori dal server. Backup della configurazione e dei dati usano la stessa chiave; il server memorizza solo la parte pubblica e può scrivere i backup ma mai leggerli. Licenza: backup della configurazione, verifica delle esportazioni probatorie, self-service nella webmail, ripristino al primo avvio e ripristino della configurazione tramite pipeline sono inclusi in ogni edizione; backup dei dati, esportazione probatoria, processi di ripristino, la parte dati del ripristino tramite pipeline e la sincronizzazione live da Business.

1. Avvio rapido: chiave, destinazione, primo backup e verifica

Destinazioni e pianificazioni si configurano in Backup e ripristino > Pianificazioni e destinazioni (solo amministratori del server). nextxch-cli accede con una chiave API o con un login amministratore.

Riferimento / configurazione
# 1. Admin > Backup & Recovery > Configuration: set up the backup key
#    (passphrase of 12+ characters or recovery key, keep it safe outside the server)
# 2. Schedules & targets: add a target (directory, SMB share \\nas\backup\nextxch or S3) and "Test"
# 3. Back up the configuration (every tier) and take it along as a file:
nextxch-cli config backup --label "before migration" -o nextxch-config.zip

# 4. Data backup (Business): full first, then incremental by schedule
nextxch-cli backup run --target nas --full
nextxch-cli backup list --target nas

# 5. Verify, with the passphrase including decryption of the sample
export NEXTXCH_BACKUP_PASSPHRASE='...'
nextxch-cli backup verify --target nas --passphrase-env NEXTXCH_BACKUP_PASSPHRASE --limit 200

2. Esportazione con valore probatorio: ZIP, manifesto, firma e verifica

I messaggi entrano nello ZIP byte per byte come .eml. manifest.json elenca ogni file con SHA-256, dimensione, hash dell'archivio, stato di integrità, conservazione e legal hold; manifest.json.sig è una firma Ed25519 sui byte esatti del manifesto, derivata dal segreto del server e identica su tutti i nodi del cluster. GET /api/compliance/exports/public-key restituisce la chiave pubblica senza accesso. L'opzione di decrittografia rimuove solo la crittografia a riposo (solo ServerAdmin e ComplianceAuditor, altrimenti 403 DECRYPT_NOT_ALLOWED); non è una decrittografia S/MIME o OpenPGP generale. Il download singolo GET /api/compliance/messages/{id}/raw restituisce gli hash come header HTTP X-Nextxch-Sha256, X-Nextxch-Stored-Sha256, X-Nextxch-Integrity e Repr-Digest. Esportazione da Business, verifica in ogni edizione.

Riferimento / configurazione
nextxch-evidence-20261111-0930-1a2b3c4d.zip
  messages/000001-<archiveId>.eml     original message, byte for byte
  messages/000002-<archiveId>.eml
  SHA256SUMS.txt                      verifiable with sha256sum -c
  manifest.json                       format nextxch-evidence-export/1, scope (incl. caseReference), items[]
  manifest.json.sig                   Ed25519: algorithm, keyId, publicKey, signedSha256, signature
  README.txt

# Start an export (202, status under GET /api/compliance/exports/{id}):
curl -X POST https://mail.company.com/api/compliance/exports -H "X-Api-Key: $KEY" \
  -H "Content-Type: application/json" \
  -d '{"scope":"mailbox","account":"anna@company.com","sinceUtc":"2026-01-01T00:00:00Z","caseReference":"Case 2026-0815"}'

# Verify offline, without access to the server (exit code 0 valid, 1 invalid/tampered, 2 usage error):
curl -s https://mail.company.com/api/compliance/exports/public-key > nextxch-evidence-key.json
nextxch-cli export verify nextxch-evidence-20261111-0930-1a2b3c4d.zip --public-key <publicKey from the file>
unzip -d export nextxch-evidence-20261111-0930-1a2b3c4d.zip && cd export && sha256sum -c SHA256SUMS.txt

3. Backup della configurazione: contenuto, crittografia, diff e ripristino parziale

Un pacchetto contiene la configurazione come codice (config/*.yaml), i file di stato senza segreti (server/*), le regole Sieve e i segreti crittografati in secrets.enc (AES-256-GCM, chiave dati cifrata per la chiave di backup; un backup manuale può avere in aggiunta una propria passphrase). Sezioni: config:<area>, dkim, passwords, tls-certificates, api-keys, sieve, server-files, licence; licence, passwords e api-keys vengono ripristinati solo se indicati esplicitamente. Per impostazione predefinita il ripristino è una simulazione con anteprima. In ogni edizione; REST sotto /api/v1/config/backups.

Riferimento / configurazione
nextxch-cli config list                                   # versions (reason: manual, pre-update, after-change, pre-restore, import)
nextxch-cli config diff 20261101T020000Z-a1b2c3 current             # difference between two versions or to the current state
nextxch-cli config backup --label "before update" --passphrase-env BACKUP_PW -o nextxch-config.zip
nextxch-cli config import -f nextxch-config.zip           # take over a package of another server

# Partial restore: preview first, then apply
nextxch-cli config restore 20261101T020000Z-a1b2c3 --sections dkim,config:domains --domain company.com --dry-run
nextxch-cli config restore 20261101T020000Z-a1b2c3 --sections dkim,config:domains --domain company.com --yes

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

4. Backup dei dati: destinazioni, formato e catalogo

Ogni esecuzione produce una versione autonoma: snapshot del database per tabella (indipendente dal provider, quindi è possibile anche il passaggio da SQLite a PostgreSQL), file di stato, il manifesto dell'archivio GoBD e tutti i blob referenziati. I blob sono indirizzati tramite SHA-256 e trasferiti una sola volta; un'esecuzione incrementale carica solo i nuovi hash. Tutto viene memorizzato crittografato nel formato NXB1 (AES-256-GCM a blocchi, legato al nome dell'oggetto). Catalogo e indice dei blob sono JSON leggibile senza segreti, il catalogo è firmato con la chiave Ed25519 dell'esportazione probatoria. Il formato completo si trova nel repository in docs/protect/backup-format.md. Da Business; REST sotto /api/admin/protect/backups (amministratori del server).

Riferimento / configurazione
<target>/                                 directory, SMB share or s3://bucket/nextxch-backup/
  nextxch-backup.json                       target marker
  keys/backup-key-<keyId>.json              public key + sealed private key
  keys/dk-<dataKeyId>.json                  data key of one run (ECDH wrapped)
  blobs/ab/cd/<sha256>.nxb                  one mail or file content, immutable
  versions/20261111T023000Z-a1b2c3/
    catalog.json  catalog.json.sig          catalog (written last = version complete) + signature
    blobs.ndjson.gz                         blob index of the version
    db/<table>.ndjson.gz.nxb                database snapshot, one file per table
    files/<path>.nxb                        state files of the data directory
    archive-manifest.json.gz.nxb            retention, legal hold, integrity chain

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

# Back up a domain or single mailboxes:
nextxch-cli backup run --target s3-fsn1 --scope domains:company.com,company.at
nextxch-cli backup run --target s3-fsn1 --scope mailboxes:anna@company.com --no-wait

5. Ripristino nella casella di posta: origine, momento, destinazione

Origini: archive (archivio GoBD), recoverable (elementi eliminati) e backup (backup dei dati). Il momento si sceglie con --point (id dello snapshot, day:yyyy-MM-dd o latest) oppure con --as-of. Destinazioni: original (cartella originale), restored (predefinita, cartella "Wiederhergestellt yyyy-MM-dd", nome tramite --label) o account (un'altra casella di posta dello stesso tenant, ad esempio la casella di un successore). I duplicati vengono saltati in base a SHA-256, Message-ID e UID, le origini restano invariate. Consentito a TenantAdmin e ServerAdmin, fino a 250.000 elementi per processo; processi da Business, policy e self-service nella webmail in ogni edizione.

Riferimento / configurazione
nextxch-cli restore points  --account anna@company.com --source backup
nextxch-cli restore browse  --account anna@company.com --source backup --point latest --folder INBOX --filter "invoice"
nextxch-cli restore preview --account anna@company.com --source archive --as-of 2026-10-31T23:59:59Z --folder "Projects/Plant"
nextxch-cli restore start   --account anna@company.com --source archive --as-of 2026-10-31T23:59:59Z \
  --folder "Projects/Plant" --target restored --label "Plant (restored)"

# Whole mailbox into a successor mailbox:
nextxch-cli restore start --account ben@company.com --source backup --point day:2026-11-01 \
  --target account --target-account successor@company.com --passphrase-env NEXTXCH_BACKUP_PASSPHRASE
nextxch-cli restore jobs --account ben@company.com

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

6. Ripristino bare-metal: nuova installazione più backup restituisce il vecchio server

Su una nuova installazione (MSI, Docker o Linux, al massimo un tenant, un dominio, un account e ancora nessun accesso amministratore) /setup/ mostra "Ripristina da backup" sotto il modulo di accesso: caricare il pacchetto, passphrase, anteprima, ripristino, facoltativamente il backup dei dati, completamento e riavvio. Accesso solo con il token di configurazione monouso che il primo avvio scrive nel log e in {DataDirectory}/first-run/setup-token.txt (header X-Nextxch-Setup-Token), oppure dal server stesso con Setup:TrustLoopback=true. Il primo accesso amministratore o Fine chiude definitivamente la procedura guidata. La chiave di backup del vecchio server non viene ripresa e va configurata di nuovo in seguito. L'indice full-text SQLite non fa parte del backup: la ricerca trova le e-mail ripristinate dopo una reindicizzazione.

Riferimento / configurazione
# Headless via CLI (same 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

# Unattended on first start (Docker Compose, Kubernetes, MSI):
environment:
  NEXTXCH_RESTORE_FROM: s3://dr-bucket/nextxch/          # .zip, directory, s3://, https:// or config-backup:<id>
  NEXTXCH_RESTORE_PASSPHRASE: ${BACKUP_PASSPHRASE}       # without: configuration without secrets
  NEXTXCH_RESTORE_DATA_FROM: s3://dr-bucket/nextxch/     # optional, location of the data backup
  NEXTXCH_RESTORE_PRUNE: "true"                          # remove bootstrap objects
  NEXTXCH_RESTORE_WITH_CREDENTIALS: "true"               # passwords, API keys, licence (default true)
  NEXTXCH_RESTORE_S3_ENDPOINT: https://fsn1.your-objectstorage.com
  NEXTXCH_RESTORE_S3_ACCESS_KEY: ${S3_KEY}
  NEXTXCH_RESTORE_S3_SECRET_KEY: ${S3_SECRET}
# Result: {DataDirectory}/pipeline-restore/first-start.json ("ok": true = variable is ignored afterwards)
# Helm: restore.from, restore.scope, restore.mapping, restore.passphrase, restore.s3.* (replicaCount: 1)

7. Deployment tramite pipeline con ripristino (nextxch-cli deploy --restore)

Un solo comando o passaggio di pipeline ricostruisce un server da un backup: applica la configurazione, ripristina i dati, esegue controlli (campione di hash, stato di salute, e-mail di test solo verso Mailpit o una casella di posta locale) e facoltativamente fornisce istruzioni per la modifica DNS/MX; il DNS non viene mai modificato automaticamente. Ogni esecuzione è idempotente e dopo un'interruzione riprende dall'ultimo passaggio completato. Il file di mappatura (kind RestoreMapping, schema sotto GET /api/v1/deploy/mapping-schema) riscrive nomi host, indirizzi IP e percorsi, stabilisce da dove provengono i certificati (backup, acme, files) e descrive database e storage del nuovo host; i domini di posta non vengono mai rinominati. Accesso con una chiave di integrazione con ambito deploy.restore. Configurazione in ogni edizione, parte dati da Business (tranne al primo avvio di una nuova installazione); la parte dati copre lo scope all.

Riferimento / configurazione
# mapping.yaml
apiVersion: nextxch/v1
kind: RestoreMapping
hostnames:
  mail.old-provider.example: mail.company.com
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@company.com}
database:
  provider: Postgres              # must match the new host (Storage__Provider)
  connectionStringEnv: NEXTXCH_PG_CONNECTION
storage:
  blobBackend: S3
  s3: {endpoint: https://fsn1.your-objectstorage.com, bucket: nextxch-mail}

# Plan (dry run, shows every replacement), then restore with checks:
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 defaults to true)
# {"source":"s3://dr-bucket/nextxch/","scope":"all","mapping":"...","dryRun":false,"testMail":"mailpit","hashSample":20}
# Local package: POST /api/v1/deploy/restore/upload (application/zip) -> source "upload:<sha256>"
# Runs: GET /api/v1/deploy/restore/runs

8. Modelli CI: GitHub Actions, GitLab CI, Azure DevOps e Ansible

I modelli si trovano nel repository in deploy/ci: ripristino con una fase di pianificazione e approvazione sull'ambiente di produzione, più un test DR notturno che ripristina in un ambiente usa e getta e scrive un rapporto con durata (RTO) e stato (RPO). I segreti vanno in variabili CI mascherate e protette; le e-mail di test vanno a un container Mailpit accanto al job e non lo lasciano mai.

Riferimento / configurazione
deploy/ci/github-actions/nextxch-restore.yml        plan on a throwaway instance, container with restore on first start, checks, DNS step
deploy/ci/github-actions/nextxch-dr-probe.yml       nightly DR probe with RTO/RPO report
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 with parameters, deployment job on environment production
deploy/ci/azure-devops/azure-pipelines-dr-probe.yml nightly DR probe, report in the run summary
deploy/ci/ansible/playbook-restore.yml              role nextxch_restore: container (Linux) or MSI (Windows)
deploy/ci/mapping.example.yaml, mapping.schema.json example and JSON Schema of the mapping file

9. Sincronizzazione live per il cambio di provider: un breve congelamento invece di un lungo fermo

Dopo il ripristino completo il nuovo server segue quello vecchio con esecuzioni delta: il vecchio server continua a scrivere il proprio backup dei dati (ad esempio ogni ora su S3) e ogni esecuzione riprende solo blob, righe di tabella e file di stato modificati dall'ultima versione ripresa. L'avanzamento si trova in {DataDirectory}/pipeline-restore/live-sync.json; eseguire di nuovo lo stesso comando non cambia nulla oppure riprende. Per il passaggio definitivo il vecchio server viene congelato manualmente (bloccare le porte di posta e dei client sul suo firewall, lasciare in esecuzione il servizio, ultimo backup con nextxch-cli backup run --full), poi --cutover --source-frozen riprende quel backup con un confronto completo delle righe. Successivamente riavviare il nuovo server e modificare il DNS. Da Business; REST: POST /api/v1/deploy/live-sync, POST /api/v1/deploy/live-sync/cutover, GET /api/v1/deploy/live-sync.

Riferimento / configurazione
nextxch-cli deploy --restore s3://dr-bucket/nextxch/ --scope all --yes                          # 1. full restore (baseline)
nextxch-cli deploy --restore s3://dr-bucket/nextxch/ --live-sync --dry-run                      # remaining delta, changes nothing
nextxch-cli deploy --restore s3://dr-bucket/nextxch/ --live-sync --interval 5m --until-cutover  # 2. follow the old server
nextxch-cli deploy --restore s3://dr-bucket/nextxch/ --cutover                                  # 3. instructions for the freeze
# old server: block ports, then  nextxch-cli backup run --full
nextxch-cli deploy --restore s3://dr-bucket/nextxch/ --cutover --source-frozen                  # 4. last backup, last run

Impostazioni, valori predefiniti e best practice

Impostazione / posizione Descrizione Valore predefinito Best practice per la produzione
Konfigurationssicherung: Versionen (#/protect/config) Versioni automatiche prima di ogni aggiornamento (AutoBeforeUpdate) e dopo le modifiche (AutoAfterChanges, raggruppate dopo DebounceMinutes), più versioni manuali, importazioni e uno snapshot di sicurezza prima di ogni ripristino. KeepLast 30 · KeepDailyDays 90 · Debounce 10 min Prima di modifiche importanti crei una versione manuale con etichetta e conservi il file .zip fuori dal server.
Sicherungsschlüssel (Passphrase / Wiederherstellungsschlüssel) ECDH P-256; la parte privata esiste solo sigillata (PBKDF2-SHA256 con 600.000 iterazioni, AES-256-GCM) e viaggia all'interno di ogni pacchetto. Senza chiave e senza passphrase un backup della configurazione non contiene segreti. nicht eingerichtet · Passphrase ab 12 Zeichen Stampi la chiave di ripristino e la conservi separata dal server; senza di essa i backup dei dati non possono essere letti.
Datensicherung: Aufbewahrung je Ziel Le KeepLast versioni più recenti più la versione più recente di ciascuna delle ultime KeepHourly ore, KeepDaily giorni, KeepWeekly settimane ISO e KeepMonthly mesi (UTC). 3 / 24 / 7 / 4 / 12 Durante una sincronizzazione live conservi almeno due versioni, altrimenti il delta non può essere calcolato (BASELINE_GONE).
S3 Object Lock (ObjectLockMode, ObjectLockDays) Gli oggetti vengono scritti in modalità Governance o Compliance con una data retain-until; i blob riutilizzati ricevono una data estesa (ora più 1,5 volte i giorni di blocco), così nessuna versione punta a un oggetto che diventa eliminabile troppo presto. Normal · 30 Tage Per la protezione dai ransomware usi la modalità Compliance su un bucket dedicato con controllo delle versioni; gli oggetti bloccati vengono rimossi solo da un'esecuzione successiva alla loro data.
Zeitpläne (Frequency, Type, Scope) Ogni ora, ogni giorno o ogni settimana, incrementale o completo, per destinazione e ambito (server, domini, caselle di posta); orario nell'ora locale del server, nessuna espressione cron. Täglich 02:30 inkr. · Sonntag 03:30 voll Le pianificazioni predefinite inizialmente non hanno una destinazione: assegni una destinazione e le attivi, altrimenti non viene eseguito alcun backup.
Automatische Prüfung (VerifyEveryHours, VerifySampleSize) Verifica gli hash memorizzati, gli header di busta, i file delle chiavi, la firma del catalogo e la leggibilità di catalogo e indice dei blob senza la chiave; con la passphrase vengono decrittografati anche il campione e tutti i file delle tabelle. alle 24 h · 50 Objekte Lasci attivo AlertOnFailure, così i backup e le verifiche non riusciti raggiungono le destinazioni degli avvisi.
Parallele Uploads je Sicherung (UploadParallelism) Numero di caricamenti simultanei verso destinazioni S3 e directory. 4 (1 bis 32) Per S3 su collegamenti veloci da 8 a 16; per un NAS su SMB lento piuttosto da 2 a 4.
SQL Server: ALLOW_SNAPSHOT_ISOLATION nextxch tenta di attivare l'isolamento snapshot all'avvio. Se è disattivato, le tabelle vengono esportate una alla volta con READ COMMITTED (coerenza read-committed) e l'esecuzione segnala un avviso. an, wenn erlaubt La panoramica mostra l'istruzione SQL da copiare; con l'isolamento snapshot lo snapshot del database è coerente a livello transazionale.
RecoverableItemsDays (restore-policy.json) Per quanto tempo appuntamenti, contatti, attività e note eliminati conservano il loro contenuto; successivamente resta solo un tombstone vuoto per la sincronizzazione. Le e-mail eliminate temporaneamente restano finché non vengono rimosse definitivamente (expunge). 14 Tage (nach Upgrade 30) Lo annoti nella documentazione delle procedure: senza un backup dei dati gli elementi groupware eliminati perdono il loro contenuto dopo questo periodo.
Selbstbedienung im Webmail (SelfServiceEnabled, SelfServiceDays) Gli utenti recuperano autonomamente e-mail ed elementi groupware eliminati in Ripristina elementi eliminati (fino a 500 per esecuzione). Configurabile per l'intero server o per dominio; 0 giorni significa nessuna finestra propria. an · 0 Tage Per i domini con regole rigorose imposti lì una finestra temporale o disattivi il self-service.
Beweisexport: Rollen, Umfang, Download Possono esportare ComplianceAuditor, TenantAdmin (solo il proprio tenant) e ServerAdmin; ambito search, mailbox, range o legalHold, fino a 100.000 messaggi (al massimo 250.000). Il link di download è valido per 24 ore. includeSoftDeleted true · 24 h Indichi sempre un riferimento della pratica (caseReference): compare nel manifesto firmato e nel registro di controllo.
Setup:TrustLoopback Consente le richieste dal server stesso (loopback) alla procedura guidata di configurazione senza il token di configurazione. Per impostazione predefinita ogni richiesta richiede il token da first-run/setup-token.txt. false Lo imposti solo su host senza altri utenti locali; altrimenti passi il token tramite NEXTXCH_SETUP_TOKEN.
Audit-Log & GoBD Ogni passaggio è nel registro di controllo: config.backup*, data.backup.*, Compliance.EvidenceExport*, Protect.Restore*, Protect.SelfRestore, Protect.RestorePolicy, setup.* e config.restore; visibile in Backup e ripristino > Log. L'archivio GoBD resta invariato a ogni ripristino. aktiv Il backup dei dati contiene il manifesto dell'archivio con conservazione e legal hold; dopo un ripristino ogni hash archiviato viene verificato e i blocchi vengono reimpostati.