Backup e disaster recovery: stati, obiettivi e ripristino operativo

Un job di backup completato con successo dimostra inizialmente soltanto che uno strumento ha scritto dei dati. Non indica ancora se il punto di backup sia completo, coerente con l’applicazione, protetto dallo stesso guasto e ripristinabile entro il tempo concordato come servizio utilizzabile. Il backup è la copia ripristinabile di uno stato precedente; il disaster recovery comprende inoltre persone, priorità, infrastruttura di destinazione, dipendenze, convalida e ritorno controllato in esercizio. NIST distingue quindi backup, strategia di ripristino, procedure di recovery, test e manutenzione continua del piano (NIST SP 800-34 Rev. 1).

Per le piattaforme di messaggistica, «il database» non è un oggetto di protezione completo. Uno stato utilizzabile può essere distribuito tra storage di mailbox o blob, metadati relazionali, code di trasporto, indici di ricerca, configurazioni, regole di routing, riferimenti alla directory, certificati, chiavi private, DNS, licenze e automazione. Alcune parti sono autorevoli, altre sono solo proiezioni e altre ancora stati transitori. Il piano di recovery deve specificare per ogni parte se viene ripristinata, ricostruita, riemessa o deliberatamente scartata. Oltre ai dati utente, NIST richiede anche stato del sistema, software, inventario, licenze e documentazione rilevante per la sicurezza; PostgreSQL, ad esempio, evidenzia espressamente che l’archiviazione WAL non include il backup dei suoi file di configurazione (NIST SP 800-34 Rev. 1, CP-9, PostgreSQL: archiviazione continua e PITR).

Il criterio operativo di accettazione non è quindi «backup montato», ma ad esempio: un mittente esterno può consegnare un messaggio, viene applicata la policy corretta, il messaggio appare nella mailbox prevista, è ricercabile e può ricevere una risposta, mentre monitoraggio e audit registrano l’operazione. NIST cita come risultati di recovery misurabili restore riusciti e tempestivi, obiettivi di recovery raggiunti e utenti o sistemi nuovamente disponibili (NIST SP 800-184, NIST SP 800-184, metriche di recovery).

L’analisi parte dal processo aziendale che deve tornare a funzionare dopo un guasto. Da questo derivano RTO e RPO, quindi la catena di backup adeguata; il risultato finale non è il job di backup, ma un test di restore misurato.

Il backup non è alta disponibilità

Backup, snapshot, replica e alta disponibilità risolvono classi di errore diverse. Microsoft descrive esplicitamente backup e replica come complementari: la replica mantiene una copia aggiornata per l’esercizio corrente, ma replica anche eliminazioni logiche o corruzioni; un backup con marca temporale consente di tornare a uno stato precedente (Microsoft Azure Reliability: ridondanza, replica e backup).

Uno snapshot può essere un componente del backup. Tuttavia, diventa una fonte di recovery affidabile solo grazie a coerenza, esportazione o replica verso uno storage gestito in modo indipendente, retention, catalogo e procedura di restore. L’API snapshot di Kubernetes, ad esempio, non garantisce di per sé la coerenza dell’applicazione; le applicazioni devono essere preparate adeguatamente prima dello snapshot. In Windows, VSS coordina questi aspetti solo se requester, writer e provider interagiscono correttamente (Kubernetes: snapshot dei volumi e coerenza dell’applicazione, Microsoft: Volume Shadow Copy Service).

MTD, RTO e RPO appartengono alle funzioni aziendali e di sistema

Il Maximum Tolerable Downtime (MTD) è l’interruzione più lunga tollerata dall’intero processo aziendale. Il Recovery Time Objective (RTO) descrive per quanto tempo una risorsa di sistema concreta può essere indisponibile prima di compromettere in modo inaccettabile altre risorse, il processo supportato o il suo MTD. Il Recovery Point Objective (RPO) indica il momento precedente all’evento fino al quale i dati devono essere ripristinati. In genere l’RTO deve essere più breve dell’MTD, poiché dopo il ripristino tecnico occorre ancora rielaborare i dati e verificare il servizio dal punto di vista operativo (NIST SP 800-34 Rev. 1, sezione 3.2).

Un unico «RTO della posta» nasconde differenze rilevanti. Una piattaforma può accettare SMTP anche se l’accesso utente o la ricerca non sono ancora disponibili. Un gateway può bufferizzare messaggi anche se il servizio mailbox a valle è indisponibile. Al contrario, un’interfaccia web può essere raggiungibile mentre mancano chiavi, lookup della directory o connettori in uscita. Gli obiettivi dovrebbero pertanto essere definiti per ogni funzione aziendale e dipendenza.

Una volta definiti gli obiettivi, occorre inventariare lo stato effettivo della piattaforma. Il solo database delle mailbox non ripristina né routing, né identità, né chiavi, né indici di ricerca.

Inventario degli stati di una piattaforma di messaggistica

Una policy di backup inizia con un inventario di stati e dipendenze, non con il catalogo dei prodotti del produttore di backup. Per ogni stato vengono documentati fonte autorevole, meccanismo di coerenza, RPO, retention, dominio di protezione, metodo di ripristino, ordine e fase di verifica. La Business Impact Analysis di NIST identifica processi critici, risorse e relativa priorità di recovery; NIST SP 800-184 aggiunge scenari realistici e dipendenze individuate durante il ripristino (NIST SP 800-34 Rev. 1, NIST SP 800-184).

Il recovery delle code è un caso particolare. SMTP richiede di eseguire in modo affidabile la responsabilità accettata, ma in caso di interruzione della connessione ammette situazioni in cui mittente e destinatario valutano diversamente il completamento. Uno stato della coda ripristinato può quindi consegnare nuovamente i messaggi. I runbook richiedono una strategia definita per i duplicati, ID delle code, finestre temporali e comunicazione ai destinatari; la semplice copia di una directory spool non è un restore conforme agli standard (RFC 5321, accodamento e messaggi duplicati).

La coerenza nasce al livello dell’applicazione

Un punto di backup coerente con un crash contiene lo stato che un sistema vedrebbe dopo un’improvvisa interruzione di corrente. Il file system e singoli blocchi possono essere coerenti internamente, mentre database, blob e code correlati rappresentano momenti diversi. Un punto di backup coerente con l’applicazione coordina buffer di scrittura, log delle transazioni, checkpoint ed eventualmente più volumi affinché l’applicazione disponga di un percorso di recovery definito.

VSS mostra esplicitamente questa architettura: il requester di backup richiede il salvataggio, il writer specifico dell’applicazione fornisce un set di dati coerente e il provider crea la Shadow Copy. Exchange fornisce a questo scopo un proprio VSS Writer; un backup compatibile con Exchange è quindi più di uno snapshot dei relativi file di database (Microsoft: Volume Shadow Copy Service, Microsoft: Windows Server Backup per Exchange).

PostgreSQL utilizza un modello di recovery diverso ma comparabile. Un backup di base fornisce il punto di partenza, una sequenza senza lacune di segmenti Write-Ahead Log archiviati lo porta fino al momento desiderato. Un pg_dump è un’esportazione logica e non sostituisce la catena di backup di base/WAL richiesta per PITR. Anche file di configurazione quali postgresql.conf e pg_hba.conf sono esterni a questo recovery WAL e richiedono un percorso di backup separato (PostgreSQL: archiviazione continua e PITR).

Per i prodotti distribuiti, la documentazione del prodotto deve chiarire se i backend vengono salvati indipendentemente, come gruppo di coerenza o tramite funzioni di esportazione proprie dell’applicazione. Uno snapshot simultaneo dello storage di più volumi non costituisce automaticamente un taglio coerente di database, object storage, coda e indice di ricerca. L’amministratore deve conoscere la fonte di verità e il percorso di ricostruzione ammesso per ogni proiezione.

Inventariare capacità e artefatti di backup

Get-Volume | Sort-Object DriveLetter |
  Select-Object DriveLetter, FileSystemLabel, Size, SizeRemaining
Get-ChildItem \\backup.example.ch\mail -File -Recurse |
  Select-Object FullName, Length, LastWriteTime

df -hT
find /backup/mail -type f -printf '%TY-%Tm-%TdT%TH:%TM:%TS %s %p\n'

Get-Volume e df mostrano la capacità occupata e libera. Get-ChildItem e find inventariano artefatti e marche temporali. Nessuno dei due dimostra né la coerenza dell’applicazione né la ripristinabilità; a tale scopo sono necessarie evidenze di catalogo, log e restore.

Architettura di protezione: separata, isolata e verificabile

Una catena di backup affidabile comprende almeno quattro ruoli distinguibili:

1. Acquisizione: l’applicazione o la funzione di esportazione genera uno stato definito.
2. Catalogo e manifest: ID di backup, fonte, momento, versione software, log necessari, riferimenti alle chiavi e checksum rendono il set reperibile e verificabile.
3. Storage di recovery: copie versionate risiedono al di fuori del dominio di errore primario e, per quanto possibile, anche del dominio amministrativo.
4. Control plane di recovery: identità separate, runbook, infrastruttura di destinazione e approvazioni consentono il ripristino quando la produzione non è affidabile.

Il CIS Control 11 richiede dati di recovery protetti in modo equivalente, un’istanza isolata ad esempio offline, nel cloud o fuori sede, nonché test di restore regolari. Per gli scenari ransomware, CISA raccomanda backup offline o altrimenti isolati, cifrati e testati regolarmente, nonché immagini pulite e un ambiente di recovery separato (CIS Control 11: Data Recovery, CISA: StopRansomware Guide).

Immutabilità e isolamento non sono la stessa cosa. S3 Object Lock può proteggere specifiche versioni di oggetti nel modello WORM dall’eliminazione e dalla sovrascrittura durante una retention o un Legal Hold. Le modalità Governance e Compliance offrono diverse possibilità di aggiramento. Ciò protegge le versioni memorizzate, ma non dimostra né credenziali separate né un endpoint di restore pulito, una catena applicativa completa o chiavi di decifrazione raggiungibili (Amazon S3: Object Lock).

Verificare checksum e manifest

Get-FileHash .\mail-backup-2026-08-08.tar.zst -Algorithm SHA256
Get-FileHash .\mail-backup-2026-08-08.manifest.json -Algorithm SHA256

sha256sum mail-backup-2026-08-08.tar.zst
sha256sum mail-backup-2026-08-08.manifest.json

Get-FileHash e sha256sum rilevano modifiche a un artefatto se l’hash previsto proviene da una fonte affidabile. Un checksum non sostituisce l’autenticazione del manifest né una prova di ripristino. NIST cita hash crittografici e firme digitali quali meccanismi per proteggere l’integrità delle informazioni di backup (NIST SP 800-34 Rev. 1, CP-9).

Chiavi e segreti costituiscono un piano di recovery separato

«Salvare tutte le chiavi private» è errato tanto quanto «i certificati possono essere riemessi». È decisivo lo scopo d’uso:

• Una chiave server TLS persa può di norma essere sostituita con una nuova coppia di chiavi e un nuovo certificato; la commutazione deve comunque rientrare nell’RTO e occorre verificare le dipendenze correlate di trust o pinning.
• Una chiave di decifrazione per dati S/MIME, OpenPGP o di backup memorizzati deve rimanere disponibile finché il testo cifrato protetto deve rimanere leggibile.
• Secondo NIST, il backup di una chiave privata di firma non è in genere auspicabile, poiché il riutilizzo può compromettere il valore probatorio della firma; eccezioni motivate richiedono un recovery particolarmente sicuro e una rapida sostituzione.
• Una chiave HSM/KMS non esportabile richiede il percorso di ridondanza, backup o reprovisioning previsto dal sistema. L’esportazione di un certificato senza chiave privata non costituisce un backup della chiave.
• La chiave che cifra il backup non deve trovarsi esclusivamente all’interno del backup cifrato o del dominio di produzione compromesso.

NIST richiede una decisione in base al tipo di chiave, metadati associati, una policy di key recovery nonché controlli di riservatezza, integrità, disponibilità e audit per il materiale di recovery. Se si perde una chiave di decifrazione, il testo cifrato non può più essere riconvertito in testo in chiaro (NIST SP 800-57 Part 1 Rev. 5, NIST SP 800-57 Part 1 Rev. 5, Key Recovery).

Verificare ora e risoluzione dei nomi prima del restore

w32tm /query /status
Resolve-DnsName -Type MX example.ch
Resolve-DnsName backup.example.ch

timedatectl status
dig +short MX example.ch
dig +short A backup.example.ch

w32tm e timedatectl verificano la base temporale per certificati, Kerberos, log e punti di recovery. Resolve-DnsName e dig mostrano se i nomi MX, di servizio e di repository vengono risolti come previsto nella zona di recovery. La fonte DNS e la relativa autorizzazione alle modifiche fanno anch’esse parte dell’inventario delle dipendenze.

Un backup coerente è solo metà del piano. Durante il restore, identità, DNS, database, coda, chiavi e applicazioni devono tornare in una sequenza motivata.

Il ripristino operativo segue il grafo delle dipendenze

Un ordine fisso dei prodotti sarebbe inventato. L’ordine affidabile deriva dalla BIA, dall’inventario delle risorse e dalle dipendenze effettive. NIST richiede un elenco prioritario delle risorse di sistema e scenari di test realistici; NIST SP 800-184 richiede che le dipendenze scoperte durante il restore vengano riportate nella documentazione (NIST SP 800-34 Rev. 1, Recovery Priorities, NIST SP 800-184, Recovery Execution). Per una tipica piattaforma di messaggistica ne deriva spesso la seguente catena, da convalidare localmente:

1. Delimitare l’evento: distinguere guasto e compromissione, preservare le evidenze, definire un punto di recovery noto e pulito e l’approvazione.
2. Ripristinare il control plane di recovery: mettere a disposizione identità amministrative separate, MFA, runbook, catalogo di backup e accesso alla decifrazione.
3. Convalidare i servizi di base: verificare nella zona di destinazione rete, routing, DNS, ora, LDAP o Kerberos, PKI/KMS e load balancer.
4. Ripristinare la persistenza: ricostruire object storage/mailbox, database e log delle transazioni necessari in un taglio coerente.
5. Avviare applicazione e policy: applicare immagini approvate, configurazione, segreti, connettori e ruoli; non consentire ancora un flusso di posta esterno non controllato.
6. Attivare coda e routing in modo controllato: valutare età, destinatari, stato dei retry e possibili duplicati; abilitare separatamente entrata e uscita.
7. Ricreare le proiezioni: generare indici di ricerca, cache e reporting dalle fonti autorevoli e monitorare il ritardo di ricostruzione.
8. Accettare la transazione aziendale: testare consegna, accesso alla mailbox, ricerca, TLS, cifratura, monitoraggio e audit rispetto ai criteri definiti.

Per un evento di sicurezza, «il sistema si avvia» non è espressamente sufficiente. NIST descrive la ricostituzione in uno stato noto e sicuro con parametri sicuri, patch, configurazione, software affidabile, backup noto e pulito e test completo. CIS formula lo stesso obiettivo come ripristino in uno «stato pre-incidente e affidabile» (NIST SP 800-34 Rev. 1, CP-10, CIS Control 11: Data Recovery).

Raggiungere endpoint di recovery e TLS

Test-NetConnection backup.example.ch -Port 443 -InformationLevel Detailed
curl.exe --verbose https://backup.example.ch/health

nc -vz backup.example.ch 443
openssl s_client -connect backup.example.ch:443 \
  -servername backup.example.ch -verify_return_error

Test-NetConnection e nc verificano il percorso TCP. curl e openssl s_client mostrano rispettivamente il comportamento HTTP e TLS. Un endpoint Health raggiungibile dimostra soltanto il control plane, non la leggibilità di tutti i set di backup.

Il ripristino operativo è concluso soltanto quando un utente o un sistema remoto può effettivamente utilizzare il servizio. Un supporto di backup letto con successo non ne è una prova sufficiente.

I test di restore misurano il servizio, non il supporto

Un test completo si svolge in un ambiente di destinazione isolato, con punto di partenza documentato, misurazione dei tempi e criteri di accettazione. Verifica almeno:

• che catalogo, credenziali, chiavi di decifrazione e artefatti siano raggiungibili senza la produzione;
• che sia possibile fornire un sistema di destinazione compatibile a partire da immagini affidabili;
• che backup di base, log delle transazioni, blob storage e configurazione producano lo stesso stato funzionale;
• che le code siano elaborate in modo controllato e i duplicati vengano rilevati;
• che identità, DNS, TLS, flusso di posta, accesso alla mailbox, ricerca e monitoraggio funzionino;
• che perdita di dati e tempo di ripristino operativo misurati rispettino RPO e RTO;
• che il servizio possa essere approvato come affidabile dopo eventi di sicurezza.

CIS Control 11.5 valuta un campione di backup ripristinati e poi effettivamente funzionanti. NIST SP 800-184 misura restore riusciti e tempestivi e richiede scenari realistici, riesame e miglioramento del piano (CIS Control 11: Test Data Recovery, NIST SP 800-184). La frequenza dei test dipende da rischio, tasso di cambiamento e requisiti; un test completo annuale può essere integrato da campionamenti automatizzati più frequenti e restore relativi ai componenti, ma non può essere sostituito da statistiche positive dei job.

Listener e stato dello storage dopo il restore

Get-NetTCPConnection -State Listen |
  Sort-Object LocalPort |
  Select-Object LocalAddress, LocalPort, OwningProcess
Get-Volume | Select-Object DriveLetter, FileSystemLabel, SizeRemaining

ss -lntup
df -hT

Get-NetTCPConnection e ss mostrano i listener locali e i processi associati. Get-Volume e df mostrano lo spazio libero. La verifica deve poi proseguire a livello di protocollo: un listener sulla porta 25 non equivale ancora a una transazione SMTP funzionante.

Scenari di errore e ambito di recovery adeguato

Un guasto determina fino a che punto deve estendersi un ripristino. La tabella collega quindi l’evento osservato al più piccolo ambito di recovery sensato e all’errata supposizione che in quel caso ricorre più spesso.

In caso di compromissione, il momento noto e pulito non deve essere per forza il punto di backup più recente. I backup più nuovi possono contenere lo stato dell’attaccante; quelli più vecchi possono introdurre vulnerabilità note o versioni software incompatibili. Il recovery unisce pertanto analisi forense, livello di patch, baseline di configurazione, rotazione delle chiavi e ripristino funzionale dei dati. CISA raccomanda tra l’altro «golden images» pulite, definizioni dell’infrastruttura mantenute offline e una zona di rete di recovery affinché i sistemi non vengano nuovamente infettati durante la ricostruzione (CISA: StopRansomware Guide).

Evoluzione tecnica

Il nastro magnetico fu introdotto all’inizio degli anni 1950 come mezzo veloce di memorizzazione dei dati per i computer e resta un supporto di backup grazie a costi, capacità e separabilità fisica (IBM: nastro magnetico). Le architetture di backup successive hanno separato sempre più il punto di backup logico dal supporto di destinazione: i database hanno combinato backup di base con log delle transazioni e Point-in-Time Recovery; i sistemi di storage hanno consentito snapshot rapidi; deduplicazione e object storage hanno modificato trasferimento e retention.

Per le applicazioni Windows in esecuzione, Microsoft ha introdotto con VSS un modello coordinato composto da requester, writer e provider; la tecnologia è comparsa con Windows XP e Windows Server 2003. Nelle piattaforme distribuite e containerizzate, le API di snapshot e orchestrazione sono state standardizzate senza risolvere automaticamente la coerenza dell’applicazione (Microsoft: Volume Shadow Copy Service, Kubernetes: Volume Snapshots).

Il cyber-recovery ha nuovamente spostato l’attenzione. Versioning e copie offsite non sono sufficienti se identità altamente privilegiate possono eliminare tutte le destinazioni o se ritornano immagini compromesse. Istanze di recovery isolate, identità separate, versioni di oggetti immutabili, infrastruttura dichiarativa e zone di ripristino pulite completano i backup classici completi, incrementali e basati su log. Amazon S3 Object Lock è stato introdotto nel 2018 come protezione WORM per le versioni di oggetti; la funzione illustra questa transizione, ma non sostituisce tuttora né la coerenza dell’applicazione né i test di restore (AWS: introduzione di S3 Object Lock, Amazon S3: Object Lock).

Checklist per amministratori

La pianificazione è affidabile solo quando obiettivi, copie, accessi e test sono documentati insieme. La checklist riassume queste dipendenze per la revisione e l’esercitazione di restore.

• Processi aziendali, MTD nonché RTO e RPO per ogni funzione di sistema sono approvati.
• Tutti gli stati autorevoli e derivati della piattaforma di messaggistica sono inventariati.
• Coerenza dell’applicazione, catena dei log e gruppi di coerenza sono documentati in modo specifico per il prodotto.
• Restore della coda, possibili duplicati e riabilitazione di entrata e uscita sono regolamentati.
• Configurazione, policy, DNS, certificati, chiavi, segreti, licenze e runbook rientrano nell’ambito.
• Almeno una copia di recovery è separata dalla produzione e dagli account amministrativi primari.
• Immutabilità, isolamento, cifratura e accesso alle chiavi sono valutati separatamente.
• Il control plane di recovery e la capacità di destinazione funzionano senza la produzione compromessa.
• L’ordine di ripristino operativo segue un grafo delle dipendenze mantenuto aggiornato.
• I test ripristinano un processo aziendale completo di posta e misurano RPO/RTO.
• Risultati, nuove dipendenze e deviazioni confluiscono nuovamente in runbook e architettura.

Fonti

• NIST – SP 800-34 Rev. 1, guida alla pianificazione di emergenza
• NIST – SP 800-34 Rev. 1, PDF
• PostgreSQL – archiviazione continua e Point-in-Time Recovery
• NIST – SP 800-184, guida al recovery dagli eventi di cybersecurity
• NIST – SP 800-184, PDF
• Microsoft Azure Reliability – ridondanza, replica e backup
• Kubernetes – snapshot dei volumi e coerenza dell’applicazione
• Microsoft Learn – Volume Shadow Copy Service
• IETF RFC 5321 – Simple Mail Transfer Protocol
• Microsoft Learn – Windows Server Backup per Exchange
• Microsoft Learn – Get-Volume
• GNU Coreutils – df
• Microsoft Learn – Get-ChildItem
• GNU Findutils – find
• CIS – Control 11: Data Recovery
• CISA – StopRansomware Guide
• Amazon S3 – Object Lock
• Microsoft Learn – Get-FileHash
• GNU Coreutils – sha256sum
• NIST – SP 800-57 Part 1 Rev. 5
• NIST – SP 800-57 Part 1 Rev. 5, PDF
• Microsoft Learn – w32tm
• systemd – timedatectl
• Microsoft Learn – Resolve-DnsName
• ISC BIND 9 – pagina man di dig
• Microsoft Learn – Test-NetConnection
• OpenBSD – pagina man di nc
• curl – pagina man della riga di comando
• OpenSSL – s_client
• Microsoft Learn – Get-NetTCPConnection
• Linux man-pages – ss
• IBM – nastro magnetico
• Kubernetes – Volume Snapshots
• AWS – introduzione di S3 Object Lock