Backup e disaster recovery

Backup e Disaster Recovery

1) Definizioni e obiettivi

Bacap è una copia coerente dei dati/configurazioni per il successivo ripristino (da rimozioni accidentali, bag, crittolocker, disastri).
DR (Disaster Recovery) - Processo di ripristino dell'infrastruttura/servizi a livello operativo dopo un grave incidente (incendio, perdita della regione, compromissione di massa).
RPO (Recovery Point Objective) - Perdita massima di dati di tempo consentita (ad esempio 15 minuti).
RTO - Tempo di ripristino mirato del servizio (ad esempio 30 minuti).

Il principio chiave è replicare i ≠. La replica «smussa» rapidamente gli errori e la crittografia su tutte le copie. Bacap è una copia isolata, collaudata, potenzialmente invariabile.

2) Classificazione dei dati e livelli di criticità

Dividere le risorse in classi:

Tier-0 (essenziali): database transazionali, pagamenti, bilanci, segreti/PKI.
Tier-1 (critici): configi di servizi, code, manufatti CI/CD, registri contenitori.
Tier-2 (importanti): analisi, report, indici secondari, loghi-archivi.
Tier-3 (ausiliari): cache, dati temporanei (è possibile ripristinare la ricostruzione).

Per ogni classe, definire RPO/RTO, conservazione, requisiti di immutabilità e posizione.

3) Strategie di conservazione: regola 3-2-1-1-0

3 copie dei dati (protesi + 2 di backup).
2 di diversi tipi di supporti/archivi.
1 copia offsite (altra regione/cloud).
1 immutable/air-gap (WORM/Object Lock/Tape).
0 errori nei controlli di ripristino (test regolari).

4) Tipi di bacap

Full è una copia completa. Lento/costoso, ma base per tutte le strategie.
Incremential è la differenza con l'ultimo bacap. Ottimizzato in volume.
Differential è la differenza con l'ultimo full. Più veloce, più spazio.
Snapshot è il calco istantaneo del volume/disco (EBS/ZFS/LVM). Sono necessari gli snapshot app-consistent (quiesce).
PITR (Point-in-Time Recovery) - Backup di base + registri (WAL/binlog) da ripristinare all'ora esatta/LSN.
Oggetti/file/Forme - Sotto tipi specifici di dati (immagini VM, S3, DAMP).

5) Coerenza dei backup

Crash-consistent: come dopo uno spegnimento improvviso - adatto per stateless/FS registrabili.
App-consistent: l'applicazione «congela» le operazioni (fsfreeze/pre-post script) per garantire l'integrità.
Consistenza database: API del backap (pgBackRest, XtraBackup), modalità hot-backup, congelamento dei checkpoint.

6) Crittografia, chiavi e accesso

Crittografia at-rest e in-transit per tutte le copie.
Chiavi in KMS/HSM, rotazione di criteri (90/180 giorni), chiavi separate per ambienti.
Separazione dei compiti: chi crea o rimuove i bacap, chi può decifrarli o leggerli.
Non tenere le chiavi di decodifica nello stesso dominio di fiducia delle copie di destinazione.

7) Copie invariate e protezione da ransomware

Object Lock/WORM (Compliance/Governance) con retensiera e Legale Hold.
Air-gap: archivio isolato/offline (nastro, cloud offline/account).
Criteri di rimozione «con attivazione ritardata», MFA-Delete, account di backup separato, impedimento di accesso pubblico.
Verifica dei malware/indicatori di compromissione prima del montaggio.

8) Frequenza, pianificazione e ritocco

GFS (Grandfather-Father-Son) - Incrementali diurni, full/diff settimanali, full mensili con conservazione prolungata.
RPO impone la frequenza incrementale e l'archiviazione WAL/binlog (ad esempio ogni 5-15 minuti).
Deposito: critici - 35-90 giorni + mensili per 12-36 mesi (richieste legali).
I picchi stagionali sono punti di controllo separati (prima delle promozioni/rilasci).

9) Modelli e script DR

Active-Active: entrambe le regioni gestiscono il traffico. RTO minimo, la combinazione dei dati richiede un criterio di conflitto rigoroso.
Active-Passive (caldo/caldo): caldo - espanso e sincronizzato (RTO minuti), caldo - parzialmente pronto (RTO orologio).
Cold: memorizzando copie e Terraform/Ansible/immagini, sollevando su richiesta (RTO 24 ore +).
DRaaS: un'orchestra di provider VM/reti/indirizzi in un'altra zona.

10) Orchestrazione del feelover e priorità di ripristino

Priorità di avvio: rete/VPN/DNS per i segreti/KMS della base/cluster della coda/ dell'applicazione perimetro/CDN dell'analisi.
Automazione: script/azioni Runbook, Terraform/Ansible/Helm/ArgoCD i profili per l'ambiente DR.
Dati: DB PITR-reindex/replica-warm-cache per l'avvio di servizi con indicatori di compatibilità degli schemi.
DNS/GSLB: abbassamento TTL in anticipo, script di transizione convalida.

11) Test di ripristino (backup verifica)

Test di restore pianificati: campionamento N% bacap, installazione in sabbia, controlli automatici schemi/invarianti.
DR-drill completo (game-day): disattiva la regione/AZ, controlla RTO/RPO sul traffico vivo (o sul traffico ombra).
Test di integrità: hash directory, checksum, tentativo di lettura di tutti i livelli (full + chain).
Rapporto: tempo, passo, anomalie, dimensione del divario dagli obiettivi, correzione.

12) Pratica per la tecnologia di base

Database

PostgreSQL: base backup + archivio WAL (PITR), strumenti pgBackRest/Barman. slot di replica, controlle'lsn '.
: Percona in Backup, archiviazione binlog.
MongoDB: mongodump per la copia logica + snapshot per i grandi set; Oplog per PITR.
Redis: RDB/AOF per critici (se Redis non solo cash), ma più spesso è la ricostruzione logica da sorgente + snapshot per incidenti.
Kafka/Pulsar: Bacap di metadati (ZK/Kraft/BookKeeper), unità disco, mirroring topic/login.

Kubernetes

etcd snapshot + Velero per risorse/volumi (CSI snapshots).
Backup dei segreti/PKI separatamente (Vault snapshot).
Registro delle immagini separato: policy di memorizzazione degli artefatti (immutable tags).

VM e file system

ZFS: 'zfs snapshot' + 'zfs send | zstd | send-recv'incremmenti, convalida' scrub '.
LVM/EBS snapshot con script pre/post (app-consistent).
Archivi oggetti: versione + Object Lock.

13) Catalogazione e controllo delle versioni dei backup

14) Osservabilità e metriche

Successo dei processi:% di successo/compromessi, motivi.
Tempo di backup/recupero, larghezza finestra.
RPO-effettivo: archivio registri (WAL/binlog) p95.
Integrità: percentuale di catene testate, errori di riconciliazione hash.
Costo: capacità di storage per classe, coefficiente di deduplicazione/compressione.
Preparazione DR: frequenza e risultato dell'esercitazione (pass/fail).

15) Criteri di accesso e compilazione

Account/progetti separati per backap Accesso di tipo NaC (non è possibile rimuovere/crittografare dal prod-screen).
Logi di accesso/modifica (audittrail), alert per cancellazioni di massa/modifiche al retensh.
Conformità: GDPR, PCI DSS (crittografia, chiavi, segmentazione), regolatori locali.

16) Anti-pattern

«Non c'è bisogno di una replica».
Nessun immutabile/air-gap: un solo errore/dannatosi cancella tutto.
I Becap sono sullo stesso account/regione della prua.
Non controllare mai il recupero (il backap è morto prima del controllo).
Nessuna catalogazione e controllo delle versioni del caos in caso di incidente.
Chiavi di crittografia condivise per tutti gli ambienti.
Snapshot senza modalità app-consistent per database.
La finestra del backup si sovrappone ai picchi (influenza p99 e SLO).

17) Assegno foglio di implementazione (0-60 giorni)

0-10 giorni

Inventario di sistemi/dati, classi di criticità.
Mostra obiettivi RPO/RTO per classe.
Abilita full + incremental per Tier-0/1, archivio WAL/binlog.
Disattiva backup: regione/account + abilita crittografia KMS.

11-30 giorni

Configura immutabile (Object Lock/WORM) per le copie critiche.
Immettere directory, tag, report Gli alert per i fallimenti e le riviste.
Il primo DR-drill è ripristinare un servizio separato dal backap in un ambiente isolato.

31-60 giorni

Automatizza runbook: Terraform/Ansible/Helm profili DR.
Test di restore regolari (settimana/mese) + script di full DR trimestrale.
Ottimizzazione dei costi: deduplicazione, compressione e cicli di vita dello storage.

18) Metriche di maturità

Test di restore: 1/ned per Tier-0 (selettivo), 1/mes è uno scenario completo.
Immutable coverage для Tier-0/1 = 100%.
RPO effettivo p95 target (ad esempio, 15 min).
RTO-effettivo nelle esercitazioni DR-target (ad esempio, 30 min).
Directory di conformità = 100% (ogni backup è descritto e convalidato).
Inserisci-to-restore - Tempo dal rilevamento all'avvio del ripristino.

19) Esempi (snippet)

PostgreSQL - Criterio PITR (idea):

bash base backup once a day pgbackrest --stanza = prod --type = full backup archive WAL every 5 minutes pgbackrest --stanza = prod archive-push restore to time pgbackrest --stanza = prod restore --type = time --target =" 2025-11-03 14:00:00 + 02"

MySQL - ciclo incrementale:

bash xtrabackup --backup --target-dir=/backup/full-2025-11-01 xtrabackup --backup --incremental-basedir=/backup/full-2025-11-01 --target-dir=/backup/inc-2025-11-02 xtrabackup --prepare --apply-log-only --target-dir=/backup/full-2025-11-01 xtrabackup --prepare --target-dir=/backup/full-2025-11-01 --incremental-dir=/backup/inc-2025-11-02

Kubernets - Velero (idee dei manifesti):

yaml apiVersion: velero. io/v1 kind: Backup metadata: { name: prod-daily }
spec:
includedNamespaces: ["prod-"]
ttl: 720h storageLocation: s3-immutable

S3 Object Lock (esempio di criterio del ciclo di vita):

json
{
"Rules": [{
"ID": "prod-immutable",
"Status": "Enabled",
"NoncurrentVersionExpiration": { "NoncurrentDays": 365 }
}]
}

20) Comunicazioni e ruoli operativi

Incident Commander, Comms Lead, Ops Lead, DB Lead, Security.
Modelli di messaggio per stakeholder, regolatori/utenti.
Post-mortem con azioni: dove perdere minuti, dove migliorare l'automazione.

21) Conclusione

Un tracciato affidabile di baccapo e DR non è «copia», ma un ciclo: classificazione dell'obiettivo RPO/RTO multi-livello e immutabile copie «runbook automatizzato» e ripristini e esercitazioni regolari. Attenersi al 3-2-1-1-0, separare la replica dai backup, cifrare e isolare le chiavi, documentare e controllare. Anche il cigno nero diventerebbe un processo controllato, con tempi prevedibili di inattività e una perdita minima di dati.

Backup e disaster recovery