Playbook di Disaster Recovery per cluster di database: ripristino operativo passo dopo passo

Un playbook di disaster recovery per cluster di database chiaramente strutturato è fondamentale nel caso di guasto di un sistema di produzione. Questo playbook fornisce una sequenza di passaggi riproducibile e verificabile per amministratori, system engineer e operatori. L’obiettivo è rispettare RTO (Recovery Time Objective, ovvero il tempo massimo di inattività accettabile) e RPO (Recovery Point Objective, ovvero la perdita di dati massima accettabile) e verificare sistematicamente il funzionamento, le interfacce e l’integrità.

Quando è necessario un playbook: cause tipiche e impatti

Un playbook viene utilizzato quando i meccanismi automatici falliscono o si verificano più errori contemporaneamente. Cause tipiche sono guasto dello storage o della rete, corruzione dei dati, aggiornamenti falliti, errori umani o malware. Le conseguenze possono variare da tempi di inattività prolungati a repliche incoerenti fino alla perdita irreversibile dei dati. Lo Split‑Brain, ad esempio, descrive la situazione in cui diversi nodi del cluster ritengono di essere il Primary; questo compromette la coerenza se non viene gestito in modo controllato.

Prerequisiti e verifiche iniziali

Prima di avviare le azioni di ripristino, eseguite un breve gate check. Se mancano autorizzazioni, chiavi o backup, qualsiasi azione successiva può causare danni.

• Comunicazione: Lista di escalation e stakeholder pronta, canali di comunicazione aperti.
• Accessi: SSH‑Key, accessi a Vault, bastion host; senza questi il recovery è spesso bloccato.
• Metadati del backup: timestamp, checksum, LSN/WAL‑marker (LSN = Log Sequence Number; importante per PITR).
• Meccanismo di quorum: Conoscenza se, ad esempio, etcd, ZooKeeper o Pacemaker gestiscono il quorum; un riavvio senza quorum può rendere il cluster inutilizzabile.
• Stato dello storage: I dischi sono online? Controllare indicatori hardware (SMART, log del controller RAID).

Disaster‑Recovery‑Playbook per cluster di database: ruoli, test e flusso

Un playbook non è solo una checklist tecnica, ma definisce anche i ruoli. Responsabilità chiare evitano loop di coordinamento che consumano tempo.

• Incident Lead: Responsabilità complessiva per decisioni, comunicazione ed escalation.
• DB‑Operator: Esegue il ripristino, il WAL‑replay e la ricostruzione della replica.
• Storage/Network‑Engineer: Verifica hardware, LAN/VLAN, MTU, I/O dello storage e permessi di accesso.
• Application Owner: Valida le interfacce, esegue test end‑to‑end e controlli di business.
• Scribe: Registra azioni, timestamp e risultati per il postmortem.

Playbook: ripristino passo dopo passo

L’ordine è importante: una sequenza errata può causare Split‑Brain, perdita di dati o tempi di inattività prolungati. Adattate i dettagli alla vostra tecnologia di database (es. PostgreSQL, Galera, MongoDB, Cassandra).

1. Creare un quadro della situazione e definire l’ambito

Individuate i nodi interessati, l’entità della perdita dei dati e i backup disponibili. Annotate le azioni già intraprese e conservate gli orari. Un quadro preciso aiuta a evitare azioni inutili.

2. Isolare e preservare l’infrastruttura

Isolate i sistemi interessati dalla rete RESTante per evitare effetti collaterali. In caso di sospetto ransomware, preservate i backup in sola lettura (es. object storage con write‑once o tape/cold‑storage separato). Evitate che un nodo avviato accidentalmente applichi modifiche a repliche integre.

3. Verifica dei backup: integrità prima del ripristino

Verificate le checksum, la completezza e i metadati. Un backup danneggiato può prolungare l’interruzione, perché si impiega tempo in azioni correttive invece che in procedure di ripristino pulite.

# Beispiel: Backup-Liste und Prüfsummen
ls -lh /mnt/backups/postgres/
sha256sum /mnt/backups/postgres/base_2026-07-25.tar.gz
jq '.' /mnt/backups/postgres/base_2026-07-25.json

Se i metadati contengono marcatori LSN/WAL, confrontateli con le ultime posizioni WAL note. Se mancano gli archivi WAL, pianificate una perdita di dati o la scelta di un backup più vecchio.

4. Configurazioni prima dei dati: perché prima i settings

I file di configurazione gestiscono i parametri di avvio, i percorsi, gli utenti di replica e le porte di rete. Un ripristino senza la configurazione appropriata spesso causa un avvio errato o impostazioni di replica incoerenti.

tar -xzf /mnt/backups/postgres/base_2026-07-25.tar.gz 
  -C /var/lib/postgresql/ --wildcards '*/postgresql.conf' '*/pg_hba.conf'

Verificate le versioni del software di database; un disallineamento tra Major‑Version spesso impedisce un ripristino diretto. Se necessario, collocate i binari della versione corrispondente in una directory di recovery.

5. Ripristino dei dati e WAL/PITR

PITR (Point‑In‑Time Recovery) combina un basebackup con archivi WAL (Write‑Ahead‑Logs). Il basebackup ripristina lo stato a un dato istante; le WAL applicano le modifiche fino al tempo di destinazione.

# Basebackup zurückspielen (Achtung: überschreibt Datenverzeichnis)
rm -rf /var/lib/postgresql/data/*
tar -xzf /mnt/backups/postgres/base_2026-07-25.tar.gz -C /var/lib/postgresql/data/

# RESTore_command konfigurieren (Beispiel)
cat > /var/lib/postgresql/data/recovery.conf <<'EOF'
RESTore_command = 'cp /mnt/backups/postgres/wal/%f %p'
recovery_target_time = '2026-07-25 10:15:00'
EOF

I fallimenti nel replay delle WAL si presentano tipicamente per segmenti WAL mancanti o corrotti o per incompatibilità nei formati WAL (p.es. Major‑Releases differenti). Se le WAL mancano, una PITR corretta non è possibile; decidete allora chiaramente tra una maggiore perdita di dati o soluzioni alternative come la ricostruzione incrementale della replicazione.

6. Ricostruire quorum e replica

Avviate di norma prima il nodo con il dataset valido (la LSN più alta). Successivamente aggiungete le repliche. PRESTate attenzione a slot di replica, utenti di replica e accesso di rete. Nei sistemi distribuiti il quorum (principio di maggioranza per decidere quali nodi siano validi) è centrale; un ripristino errato del quorum può favorire incoerenze.

-- Prüfen, ob Instanz in Recovery ist
SELECT pg_is_in_recovery();
-- Aktuelle WAL-Position
SELECT pg_current_wal_lsn();
-- Replikationsstatus
SELECT pid, application_name, state, sync_state FROM pg_stat_replication;

7. Interfacce e test dell’applicazione

Eseguite test di connessione e smoke test. Verificate i percorsi di lettura e scrittura su tabelle di test isolate, controllate le verifiche di business (ad es. conteggi di righe, checksum di controllo) e lanciate un Canary‑Release prima di riattivare l’endpoint del database.

-- Health-Checks
SELECT count(*) FROM important_business_table;
SELECT md5(string_agg(id::text || ':' || coalesce(data,''), ',')) FROM kontrolle_tbl;

# Beispiel HTTP-Healthcheck für Anwendung (kein Produktionsdaten eingesetzt)
curl -sSf https://app.example.local/health || echo 'Healthcheck failed'

Sequenza di controllo tecnica: verifiche approfondite

Dopo il ripristino iniziale dovete eseguire una sequenza di verifiche per rilevare precocemente eventuali stati incoerenti. L’ordine è voluto: consistenza, integrità, pRESTazioni, interfacce.

1. Integrità del file system: Verificare permessi, proprietari e dimensioni dei file dei database (DB).
2. Stato del WAL‑Replay: Controllare i log per errori, confronto LSN con i metadati del backup.
3. Integrità degli indici: Pianificare la ricostruzione degli indici se risultano incoerenti.
4. Replication Lag: Monitorare latenze e code di replica.
5. Application Tests: Pool di connessioni, prepared statements, compatibilità delle migrazioni.

Comandi pratici di verifica:

# Dateisystem- und Rechte-Check
ls -la /var/lib/postgresql/data
# Systemd-Status
systemctl status postgresql
# Storage-IO-Check (kurz)
iostat -x 1 3
# LUKS-Header-Check (falls verschlüsselt)
cryptsetup luksDump /dev/sdb1

Cloud vs On‑Prem: Besonderheiten

Gli ambienti cloud presentano insidie specifiche: gli snapshot sono spesso consistenti a livello di VM, ma non necessariamente a livello applicativo (quiesce). L’object-storage ha latenze e costi di egress; il ripristino di grandi volumi di dati richiede pianificazione della banda. On‑Prem offre spesso accesso diretto allo storage e I/O più veloci, ma implica maggior responsabilità sull’hardware.

• Cloud-Snapshots: Verificare se è stato utilizzato Guest‑Quiesce o uno snapshot application-aware.
• Objekt-Storage: Verificare le policy di accesso, il versioning e il lifecycle (MFA Delete può bloccare il ripristino).
• Netzwerk-Architektur: VPN/Peering, timeout BGP e allineamento MTU sono frequenti cause di interruzione del ripristino.

Testplan, Metriken und Automatisierung

Programmate test di ripristino periodici. Metriche da misurare:

• Time-to-First-Byte (TTFB) del ripristino — Tempo fino a quando i primi dati validi sono nuovamente disponibili.
• Time-to-Service — Tempo fino a quando le interfacce per l’applicazione sono nuovamente disponibili (catena RTO).
• Data‑Drift dopo il ripristino — Conteggi delle righe, checksum, controlli di business.

I test automatizzati dovrebbero essere eseguiti in un ambiente isolato e seguire la stessa sequenza di verifica descritta sopra. Esempio: un job Cron/CI che ripristina il basebackup, applica i WAL, poi esegue gli script di verifica e registra i risultati in un reporting.

# Minimaler CI-Job-Flow (schematisch)
# 1) Provision Test-VM
# 2) Mount Backup-Archive
# 3) RESTore Basebackup
# 4) Start DB, apply WAL
# 5) Run verification scripts
# 6) Report result (OK/FAIL)

Häufige Fehler und gezielte Troubleshooting-Schritte

Un breve promemoria di troubleshooting con sintomi tipici:

• DB startet nicht: DB non si avvia: controllare i log (/var/log/postgresql/) e i permessi della directory dei dati.
• WAL‑Replay stoppt mit Fehler: Il WAL‑replay si interrompe con un errore: segmento WAL mancante o errore di checksum — verificare la cartella dei WAL del backup e l’integrità.
• Replikation verbindet nicht: La replica non si connette: verificare firewall, Repl‑User, certificati SSL e pg_hba.conf / equivalente.
• Split‑Brain Anzeichen: Segni di split‑brain: primary differenti, LSN divergenti — isolare i nodi, utilizzare un Quorum‑Tool.

# Repl-Verbindungscheck (Postgres, Beispiel)
psql -c "SELECT client_addr, state, sync_state FROM pg_stat_replication;"
# Prüfen, ob WAL-Archivelogs lesbar sind
file /mnt/backups/postgres/wal/0000000100000000000000A9
sha256sum /mnt/backups/postgres/wal/0000000100000000000000A9

Strategia di rollback e di fallback

Definire un criterio chiaro per l’interruzione dell’operazione (es. WAL mancanti, incongruenze dopo il replay, quorum non raggiungibile). Elementi di rollback:

• Snapshot di configurazione prima delle modifiche.
• Script di rollback per configurazioni e binari.
• Ambiente di test isolato per il tentativo finale di RESTore.
• Protocollo di allineamento con gli stakeholder e piano di comunicazione.

Postmortem e miglioramento continuo

Documentare cause, tempistiche, backup utilizzati, decisioni e lessons learned. Miglioramenti tipici dopo un incidente sono: validazione automatica delle checksum, test di RESTore più frequenti, alerting per WAL‑Lags e controlli di monitoraggio aggiuntivi per lo stato di salute dello storage. Utilizzare le evidenze per adeguare gli obblighi SLA e aggiornare i runbook interni.

Checklist per la riattivazione (compatta)

1. Verifiche preliminari: accessi, contatti, metadati presenti?
2. Backup validati: checksum, LSN, WAL presenti?
3. Configurazioni ripristinate e versioni verificate?
4. Basebackup + WAL/PITR eseguiti in conformità con l’ora obiettivo?
5. Quorum/replicazione ripristinati nell’ordine corretto?
6. Applicazioni verificate: Health, controlli di business, Canary‑Release?
7. Postmortem pianificato e misure definite?

Conclusione

Un solido Disaster-Recovery-Playbook per Datenbank-Cluster è una combinazione di tecnologia, processo e comunicazione. Fondamentali sono passi di RESTore riproducibili, validazioni automatizzate, gestione pulita delle configurazioni e regole chiare di fallback. Investite in test di RESTore, nel monitoring delle pipeline dei WAL e in script semplici e idempotenti — così ridurrete l’RTO e il rischio di perdita di dati.

Questo playbook è intenzionalmente generico. Adattate i passaggi alla vostra specifica tecnologia di database e infrastruttura e integrate gli approcci di automazione descritti nelle vostre procedure operative.

Disaster-Recovery-Playbook per cluster di database: aspetti architetturali e operativi

Oltre alla sequenza concreta di RESTore conviene estendere il playbook dal punto di vista architetturale. Cruciali sono separazioni nette tra Control‑Plane (dati di configurazione e orchestrazione), Data‑Plane (file dati, WAL) e artefatti di recovery (basebackup, checksum, metadati). Una separazione pulita riduce il blast‑radius e semplifica la validazione automatizzata.

Rischi rilevanti spesso sottovalutati:

• Konfigurationsdrift: Configurazioni diverse tra ambiente di produzione e recovery portano a comportamenti imprevisti. Versionate gli snapshot di configurazione in Git e testate i rollback regolarmente.
• Time‑Skew: Orologi non sincronizzati impediscono il corretto raggiungimento degli obiettivi PITR. NTP/chrony devono essere attivi nelle VM di recovery, altrimenti il ripristino all’ora target fallirà.
• Silent Corruption: Dedupe dello storage o errori di compressione possono corrompere i backup senza generare errori immediatamente visibili. Implementate controlli di checksum e verifiche periodiche di RESTore completo.

Pratiche indicazioni architetturali per un’operatività robusta:

• Backup immutabili: Conservi i basebackup in sola lettura (WORM/immutable Object Storage) e mantenga i metadati (LSN, DB‑Version, checksums) come file separato e versionato.
• Gestione Out‑of‑Band: Si assicuri che BMC/Redfish o la console seriale siano raggiungibili; senza accesso Out‑of‑Band il recovery hardware può richiedere tempi sproporzionati.
• Script di recovery idempotenti: I passaggi di recovery dovrebbero poter essere eseguiti in sicurezza più volte. L’idempotenza riduce i rischi durante i tentativi ripetuti sotto pressione temporale.
• Osservabilità: Esporti durante il RESTore metriche critiche (LSN‑Progress, WAL‑Throughput, I/O‑Latency) nel suo sistema di monitoring, così da poter prendere decisioni precise sull’interruzione.

Integrazione in CI/CD e automazione:

Le pipeline di RESTore automatizzate (p. es. in CI) dovrebbero essere eseguite su infrastruttura isolata e utilizzare le stesse versioni software della produzione. Implementi un piccolo template di job di verifica che, dopo l’applicazione del basebackup e dei WAL, esegua controlli di base:

#!/bin/bash
# vereinfachter Verifikator: checksum + LSN-Check
sha256sum -c /backups/base_2026-07-25.sha256 || exit 1
psql -Atc "SELECT pg_last_wal_replay_lsn()" | tee /tmp/last_lsn
# vergleichen mit erwarteter LSN
[ "$(cat /tmp/last_lsn)" = "0000000100000000000000A9" ] || exit 2
echo "verification ok"

Esegua questi job regolarmente, non solo in caso di incidente. Forniscono la certezza che i backup non siano solo presenti ma anche utilizzabili.

In conclusione: radichi artefatti di recovery, script di test e runbook come codice nel suo repository, firmi le release critiche e eserciti le vie di escalation – così il suo Disaster‑Recovery‑Playbook diventa solido e operativo.

Per questo tema sono importanti anche il ripristino del database e Rto Rpo. Il contributo contestualizza questi aspetti e mostra cosa conta nella pratica quotidiana.