Ripristino in caso di disastro: runbook, test di failover e comunicazione

Il ripristino in caso di disastro non è una singola azione, ma una catena di decisioni, dipendenze e manovre eseguite correttamente. Nella pratica i tentativi di ripartenza raramente falliscono perché «non esiste alcun backup». Più spesso i runbook sono incompleti, le responsabilità non sono chiare, le vie di failover non sono mai state testate realmente o la comunicazione crea pressione inutile e priorità errate.

Questo contributo è rivolto ad amministratori, ingegneri di sistema, operator e fornitori di servizi IT tecnici. Il focus è su un approccio pratico: come scrivere runbook in modo che funzionino sotto stress, come pianificare test di failover senza mettere a rischio la produzione e come stabilire comunicazione e percorsi decisionali in modo che i team tecnici RESTino operativi. Gli esempi si riferiscono a configurazioni tipiche di MariaDB (replicazione, backup, Point-in-Time-Recovery), ma includono intenzionalmente anche temi di infrastruttura come DNS, load balancer, identità e monitoring.

Ripristino in caso di disastro nella pratica

Un «disastro» è operativamente meno un singolo evento e più uno stato: un servizio non è utilizzabile, la causa non è immediatamente chiara e la normale catena di cambi e approvazioni è troppo lenta. Trigger tipici sono ransomware (inclusi account amministrativi compromessi), guasti di storage, errori durante aggiornamenti, interruzioni del cloud/provider, problemi a livello di segmento di rete o corruzione logica dei dati (es. un’applicazione scrive dati errati).

I runbook falliscono spesso per gli stessi motivi:

• Assunzioni errate: «l’host di monitoring è attivo», «DNS è disponibile», «abbiamo accesso a Internet», «i backup sono leggibili».
• Passi troppo generici: «RESTore DB» senza indicazioni su versione, modalità di recovery, validazione, dipendenze e punto di ritorno.
• Nessun punto decisionale: i runbook richiedono chiare diramazioni «se-allora» (p. es. corruzione dei dati vs. guasto infrastrutturale).
• Comunicazione non consolidata: il team tecnico viene sommerso da richieste di stato, mentre non vengono prese decisioni (p. es. accettare la perdita di dati?).

Il rimedio è una combinazione di (1) runbook ben strutturati, (2) test realistici, (3) chiara distribuzione dei ruoli e (4) regole di comunicazione che supportino il ripristino tecnico invece di ostacolarlo.

RTO und RPO: Ziele definieren, bevor Sie ein Runbook schreiben

Senza valori-obiettivo ogni runbook sarà o troppo prudente (troppo lento) o troppo rischioso (troppa perdita di dati). Due termini sono centrali:

• RTO (Recovery Time Objective): tempo obiettivo entro cui il servizio è nuovamente utilizzabile. In pratica significa: quando gli utenti possono riprendere a lavorare, non quando è «tutto perfetto».
• RPO (Recovery Point Objective): perdita massima di dati tollerabile misurata nel tempo. In pratica: «nel peggior caso possiamo tornare indietro solo fino a 15 minuti».

Per MariaDB ciò significa spesso: l’RTO è limitato dalla durata del RESTore, dalla commutazione di DNS/load-balancer, dall’invalidazione della cache dell’applicazione e dalla compatibilità dello schema. L’RPO dipende dal ritardo di replica, dagli intervalli di backup e dal Point-in-Time-Recovery (PITR, ripristino fino a un punto temporale basato sui log binari).

Importante: registrate RTO/RPO per servizio, non „per il database“. Un database può funzionare a livello tecnico, mentre il software di business rimane inutilizzabile a causa di secret mancanti, endpoint errati o job guasti.

Progettazione del runbook: struttura, ruoli e regole „Stop-the-Line“

Un runbook è un manuale operativo per la gestione delle interruzioni. Deve essere comprensibile in 2–3 minuti e al contempo sufficientemente approfondito da rendere decisioni e azioni affidabili. La struttura che si è dimostrata efficace è la seguente:

1) Header: scopo, ambito, prerequisiti

• Scopo: „Ripartenza del servizio MariaDB X dopo il guasto totale del datacenter primario“.
• Ambito: quali sistemi sono inclusi (DB, proxy/load balancer, DNS, monitoring, backup storage, segreti)?
• Prerequisiti: accessi (account Break-Glass), copie offline, chiavi/password, rete di emergenza.

2) Modello dei ruoli: chi decide, chi esegue

In caso di disastro la parallelità è cruciale. Definite almeno:

• Incident Lead: coordina, stabilisce priorità, protegge il team dai cambi di contesto.
• DB Operator: esegue i passaggi su MariaDB, documenta tempi e riscontri.
• Infra Operator: DNS, load balancer, storage, rete, VM/container, percorsi di accesso.
• Comunicazione: aggiornamenti di stato, stakeholder, eventualmente ticket al provider.

Le regole „Stop-the-Line“ devono essere incluse esplicitamente nel runbook: in quali situazioni si interrompe immediatamente (es. sospetto di ransomware attivo, integrità dei dati incerta, lacune inspiegabili nei binlog)? Questo evita un riavvio frettoloso in un ambiente ancora compromesso.

3) Albero decisionale: Failover o RESTore?

I runbook non dovrebbero limitarsi a elencare passaggi, ma definire percorsi. Domanda fondamentale: Failover (commutazione su un ambiente standby esistente) o RESTore (ripristino dai backup). Il failover è generalmente più veloce (RTO), il RESTore può essere più pulito (sicurezza/integrità) – specialmente dopo ransomware o corruzione logica.

Fondamenti tecnici per MariaDB-DR: replica, backup, PITR

Per MariaDB in ambiente aziendale sono tipici tre elementi:

• Replicazione: i sistemi secondari ricevono le modifiche dalla DB primaria. A seconda della configurazione asincrona o semi-sincrona. Rischio: la replicazione trasferisce anche modifiche „cattive“ (corruzione, cancellazioni).
• Backup fisico/logico: il fisico (a livello di file, es. procedure compatibili con Percona XtraBackup) è generalmente più veloce nel RESTore; il logico (mysqldump) è più portabile ma lento con grandi volumi di dati.
• PITR (Point-in-Time-Recovery): ripristino a un punto temporale tra un backup e il „presente“ tramite binlog (registri binari delle modifiche). Prerequisito: i binlog sono completi, ordinabili temporalmente e disponibili.

Un runbook DR deve specificare concretamente quale combinazione si usa: „Failover su Replica A“ è diverso da „RESTore dell’ultimo backup completo + binlog fino a T-15min“. E: per MariaDB la verifica dell’integrità (es. controlli delle tabelle, sanity-checks dell’applicazione) dopo il riavvio è spesso il collo di bottiglia, non la copia dei dati.

Preparazione: cosa deve essere documentato e reso disponibile prima del disastro

Molti disastri falliscono a livello operativo perché mancano i „piccoli dettagli“. Questa checklist è volutamente pragmatica e redatta dal punto di vista operativo:

Identità e accessi (Break Glass)

Per „Break Glass“ si intendono accessi di emergenza, gestiti separatamente dagli account amministrativi normali e protetti in modo particolare (es. token MFA conservati offline, credenziali sigillate, policy password separate). Importante per il DR:

• Accesso SSH/RDP di emergenza verso una rete amministrativa isolata
• Accesso DB-Admin che non dipenda da SSO/IdP (IdP = Identity Provider, autenticazione centrale)
• Accesso al repository di backup e al materiale di chiavi (crittografia, Object-Storage-Keys)

Inventario di configurazione e dipendenze

Al minimo: versioni (MariaDB, OS, Proxy), parametri (innodb_flush_log_at_trx_commit, binlog_format), topologia (Primario/Replica, GTID sì/no), nomi DNS, porte, regole firewall, classi di storage, controlli di monitoring, cronjob/lavori batch. Senza queste informazioni ogni ripartenza si trasformerà in un rebuild improvvisato.

Percorso offline e „No-Internet“

Pianificate il caso in cui né Internet né la console cloud siano raggiungibili. Sembra estremo, ma è realistico in caso di interruzioni del provider, problemi BGP o incidenti di sicurezza. Misure pratiche:

• Copia offline dei Runbooks (PDF/stampa) e dei principali secrets (conservati in modo sicuro)
• Repository/cache locale per pacchetti o immagini container (altrimenti il rebuild fallirà per il download)
• Accesso out-of-band (es. iLO/iDRAC/IPMI o accesso console seriale) su rete separata

Test di failover: tipologie, rischi e criteri di successo

I test di failover non sono un „evento“, ma un processo ripetibile. È fondamentale definire criteri di successo che vadano oltre il semplice „ping raggiunge“. Per MariaDB e i servizi dipendenti, i test dovrebbero coprire almeno: accesso in scrittura/lettura, consistenza delle transazioni, login dell’applicazione, job/queue critici, reporting, oltre a monitoring/alerting.

Tipologie di test (dal più sicuro al più realistico)

• Tabletop/Walkthrough: il team percorre il Runbook senza modificare i sistemi. Buono per ruoli e comunicazione, debole per i dettagli tecnici.
• Failover simulato in Test/Staging: tecnicamente utile, ma spesso dati e profili di carico diversi.
• Failover pianificato in produzione: alto ritorno informativo, ma deve essere preparato accuratamente (fenestre di manutenzione, rollback, stakeholder).
• Drill di failover non pianificato: approccio „chaos“ con elementi sorpresa. Solo per team maturi e automazione stabile.

Trappole tipiche nei MariaDB-Failover

• Replica lag: il ritardo di replica porta a un RPO maggiore del previsto. Cause frequenti: colli di bottiglia I/O o transazioni di grandi dimensioni.
• Read/Write-Splitting: Applicazioni o proxy (z. B. ProxySQL) usano endpoint differenti; dopo un failover continuano a scrivere su „read-only“ o nella direzione sbagliata.
• DNS-TTL: Un TTL troppo lungo (Time To Live, durata della cache) ritarda la commutazione. Un TTL troppo corto aumenta il carico e la suscettibilità a errori.
• GTID/Position-Drift: Se topologia e posizione di replica non sono documentate correttamente, si rischia uno Split-Brain (due sistemi primari).
• Security-Regression: Le modifiche d’emergenza eludono le misure di hardening (firewall „aperta brevemente“, diritti utente non correttamente configurati).

Test minimo di failover (pratico, in 60–120 minuti)

Se disponete solo di finestre di manutenzione limitate, priorizzate un test che fornisca il massimo valore informativo:

1. Bloccare le modifiche: interrompere i Deployments, mettere in pausa i job batch, ridurre il carico di scrittura.
2. Verificare lo stato delle repliche: la replicazione deve „catch up“, documentare il lag.
3. Commutazione: puntare l’endpoint dell’applicazione sulla replica, impostare il primario in read-only o isolarlo.
4. Sanity-Checks: Login, test di lettura/scrittura, i report e i job più importanti.
5. Rollback: ripristinare la configurazione precedente o mantenere il nuovo primario, ma decidere in modo chiaro.
6. Attività post-intervento: ticket per le lacune rilevate, aggiornare il runbook, registrare i tempi.

Runbook di RESTore per MariaDB: sequenza di passi, verifiche, strategia di fallback

Il RESTore è la via „dura“, perché comporta più variabili sconosciute: consistenza dei backup, chiavi, performance del ripristino e, soprattutto, validazione. Un buon runbook di RESTore separa rigorosamente: Ripristino (reintrodurre i dati) e Rimessa in servizio (rendere il servizio operativo).

Fase 1: chiarire la situazione e definire lo stato obiettivo

• Classe dell’incidente: guasto infrastrutturale, corruzione dati, incidente di sicurezza (z. B. Ransomware)?
• Punto obiettivo: „ultimo backup consistente“ o PITR fino al tempo T?
• Decisione sul rischio: compromesso RPO (perdita dati) vs. RTO (tempo). Questa decisione deve essere presa consapevolmente e documentata.

Soprattutto in caso di corruzione logica, il failover su replica è pericoloso, perché le modifiche sbagliate potrebbero essere state replicate. In questi casi il RESTore/PITR è di solito la via più sicura.

Fase 2: predisporre l’infrastruttura (senza scorciatoie)

Il ripristino fallisce spesso per motivi apparentemente banali: versioni pacchetto errate, parametri kernel mancanti, opzioni del filesystem diverse, volumi troppo piccoli o impostazioni InnoDB incompatibili. Documentate nel runbook:

• Forma target: VM, Bare Metal, Container (e quale classe di storage)
• Capacità: dati + overhead per il RESTore (spesso molto maggiore temporaneamente)
• Rete: segmento, Firewall, aprire solo le porte necessarie
• Sincronizzazione temporale: NTP/Chrony (importante per log, riferimento temporale dei Binlog, audit)

Fase 3: individuare il backup, verificarne l’integrità e renderlo ripristinabile

La verifica è obbligatoria. „Backup vorhanden“ non è prova di „Backup lesbar“. Controllare almeno: esistenza, dimensione/andamento, Prüfsummen, chiavi di cifratura, permessi di accesso e se il backup consistente è stato creato.

Esempio: un semplice controllo indipendente dal repository per file di archivio (integrità e possibilità di estrazione) può essere il seguente:

#!/usr/bin/env bash
set -euo pipefail

BACKUP_TAR="/mnt/backup/mariadb-full-2026-07-28.tar.gz"
SHA_FILE="${BACKUP_TAR}.sha256"

# 1) Prüfsumme verifizieren
sha256sum -c "$SHA_FILE"

# 2) Archiv testweise lesen (ohne zu extrahieren)
tar -tzf "$BACKUP_TAR" > /dev/null

echo "Backup-Archiv ist lesbar und Prüfsumme passt."

Perché funziona: Prüfsummen rilevano errori silenziosi a livello di bit; il test di elenco dell’archivio tar rileva compressioni difettose o strutture del contenitore corrotte. Quando fallisce: se il backup è integro come file ma incoerente nel contenuto (ad es. nessun snapshot consistente, tablespace mancanti, binlog incompleti). Per questo è necessaria una validazione vicina al DB (vedi sotto).

Fase 4: eseguire il RESTore (fisico/logico) e poi validarlo

Il metodo di RESTore concreto dipende dalla procedura di backup. Importanti per il runbook sono i punti di controllo universali:

• Avviare il DB in stato controllato: non lasciare applicazioni connesse; consentire l’accesso in scrittura solo dopo il superamento della validazione.
• Fase di sola lettura: prima solo leggere/verificare, poi autorizzare il carico in scrittura.
• Controlli di schema/migrazione: lo schema è compatibile con la versione dell’applicazione? Altrimenti possono insorgere errori successivi.

Un blocco SQL pratico per controlli di plausibilità rapidi (senza addentrarsi nelle internals del motore):

-- Verbindung und Grundzustand
SELECT VERSION() AS mariadb_version;
SHOW VARIABLES LIKE 'read_only';
SHOW VARIABLES LIKE 'innodb_flush_log_at_trx_commit';

-- Replikations-/Binlog-Relevanz (falls genutzt)
SHOW VARIABLES LIKE 'log_bin';
SHOW BINARY LOGS;

-- Grobe Konsistenzsignale: Tabellenstatus und Fehler
SHOW DATABASES;
-- Für ausgewählte Kern-Tabellen (Beispielnamen anpassen):
CHECK TABLE app.core_customer;
CHECK TABLE app.core_order;

Perché aiuta: verificate se siete sulla versione prevista, se il server non è accidentalmente scrivibile, se sono presenti Binlogs (rilevanti per PITR e replica successiva) e se le tabelle centrali appaiono almeno superficialmente coerenti. Limiti: CHECK TABLE non è una panacea, e InnoDB può manifestare alcuni problemi solo sotto carico. Integrare quindi controlli di sanity dell’applicazione (login, processi core, report critici).

Fase 5: eseguire correttamente il PITR (Point-in-Time-Recovery)

PITR significa: ripristinate un backup completo e poi applicate i Binlogs fino a un istante definito. Perché ciò funzioni, i Binlogs devono essere completi e temporalmente univoci. Insidie tipiche:

• Fusi orari/deriva dell’orologio: lo scostamento temporale complica la decisione del «Stop-Date-Time».
• Lacune nei Binlog: file mancanti per retention, errori di storage o offloading errato.
• Obiettivo temporale impreciso: il business dice „vor dem Fehler“, ma il momento dell’errore non è correlato con precisione (Logs!).

Nel runbook dovRESTe pertanto prevedere: (1) linea temporale dal monitoraggio/log delle applicazioni, (2) definizione chiara di „letzter guter Commit“, (3) sequenza di comandi documentata e adeguata al vostro tooling. Se utilizzate mysqlbinlog, testate il processo regolarmente in un ambiente isolato, perché piccoli errori di parametro (p. es. errata interpretazione delle GTID) altrimenti emergono solo in caso reale.

Fase 6: Strategia di fallback (Rollback) per il ripristino

Un ripristino può fallire: backup corrotto, chiave errata, il ripristino richiede più tempo dell’RTO, o la validazione fallisce. Pianificate quindi il fallback non come „proviamo ancora“, ma come opzione definita:

• Piano B Failover: Se il ripristino richiede troppo tempo, passare a una replica con perdita di dati accettata.
• Piano C Operatività minima: Modalità di sola lettura per le funzioni fondamentali (p. es. reporting) con comunicazione chiara.
• Percorso forense: In caso di incidente di sicurezza: isolare i sistemi, nessuna „azione di pulizia“ senza autorizzazione.

Comunicazione in caso di disastro: ritmo, contenuti, registro decisionale

La comunicazione in emergenza è un fattore tecnico, perché determina attenzione e throughput. Un modello collaudato è un ritmo di aggiornamento fisso (p. es. ogni 15–30 minuti) e un formato di stato uniforme. Questo riduce le richieste di chiarimento e previene dichiarazioni contraddittorie.

Template di stato (breve, ma robusto)

• Cosa è interessato? Servizio/ambito, impatto sugli utenti.
• Cosa è noto? Causa come ipotesi, non come affermazione.
• Cosa stiamo facendo? Passo concreto (failover in corso, ripristino in corso, validazione).
• Qual è il rischio? Finestra di perdita dati (RPO), rischio di integrità, rischio di sicurezza.
• Quando prossimo aggiornamento? Orario fissato.

Mantenete parallelamente un registro decisionale: chi ha deciso quando quale compromesso RPO/RTO accettare? Questo non è burocrazia, ma protegge il team in seguito e aiuta nelle verifiche di audit.

Trappole nella comunicazione

• La tecnica diventa un „Live-Ticker“: Un operatore non dovrebbe contemporaneamente eseguire il ripristino e gestire gli stakeholder.
• Precisione errata: „Di nuovo online in 12 minuti“ è spesso poco serio. Meglio: „Ripristino in corso, prossimo traguardo: validazione in ca. 30–45 minuti, poi ETA“.
• Nessun chiaro „Go“: Chi autorizza che si possa ricominciare a scrivere? Questo è un punto decisionale definito.

Passaggi di verifica e troubleshooting: quando Failover/RESTore non procedono come previsto

Nei riavvii reali spesso si tratta di poche classi di errore ricorrenti. Un buon runbook contiene pertanto brevi blocchi di troubleshooting con „Sintomo → Verifica → Azione“.

Sintomo: l’applicazione non si connette al DB dopo il failover

• Verifica: Il DNS punta ancora al vecchio endpoint? TTL/cache? Health checks del load balancer?
• Verifica: Regole firewall nel segmento DR? Security Groups? NAT?
• Azione: Verifica di Nome → IP, port reachability, poi controllare config/segreti dell’applicazione.

Un rapido controllo di rete da un host applicativo (esempio) può essere il seguente:

#!/usr/bin/env bash
set -euo pipefail

DB_FQDN="db.service.example"
DB_PORT="3306"

echo "DNS-Auflösung:";
getent hosts "$DB_FQDN" || true

echo "Port-Test:";
( echo > /dev/tcp/$DB_FQDN/$DB_PORT ) && echo "Port offen" || echo "Port blockiert/timeout"

Perché aiuta: separa la risoluzione dei nomi dalla raggiungibilità delle porte. Dove fallisce: /dev/tcp è specifico di bash e non è sempre disponibile; in tali ambienti servono nc/telnet o strumenti adeguati.

Sintomo: la replica è in sola lettura dopo il failover o si comporta in modo incoerente

• Check: read_only/super_read_only impostati? (In alcuni setup HA intenzionale.)
• Check: la configurazione di replica è ancora attiva e continua a scrivere „da dietro“?
• Intervento: stabilire chiaramente il ruolo primario, impostare gli altri nodi in read-only e/o ricollegarli come replicanti.

Sintomo: il ripristino dura „all’infinito“

• Check: pRESTazioni dello storage (IOPS/throughput), colli di bottiglia CPU, compressione/decrittazione
• Check: volume di destinazione troppo piccolo o filesystem errato (es. noatime, opzioni di journaling)
• Intervento: parallelizzazione solo dove tooling e storage la supportano; altrimenti attivare il piano B.

Rendere misurabile la qualità dei runbook: „Definition of Done“ per il DR

Altrimenti i runbook diventano documenti che nessuno vuole toccare. Definite criteri di qualità oggettivi:

• Eseguibile nella pratica: tutti gli accessi, i percorsi, le dipendenze sono disponibili (incluso offline).
• Testato: ogni variante critica del runbook (failover, ripristino, PITR) è stata esercitata almeno una volta.
• Marca temporale: ultimo test, ultima modifica, ruolo responsabile.
• Validazione: criteri di accettazione chiari che definiscono quando il „servizio è ripristinato“.
• Rollback: per ogni passo significativo esiste un’opzione di rollback.

Per MariaDB è consigliabile inoltre stabilire un ritmo fisso: piccole prove di ripristino (es. mensili) con dati minimi e un’esercitazione end-to-end più ampia (es. trimestrale o semestrale) in funzione della frequenza di cambiamento e del rischio.

Conclusione pratica: il disaster recovery è una procedura operativa consolidata

In caso di disastro prevalgono i team che hanno preso decisioni in anticipo: RTO/RPO per servizio, percorsi chiari di failover vs. RESTore, accessi protetti e uno schema di comunicazione che tutela la parte tecnica. Un runbook non è allora „documentazione“, ma uno strumento: rende i passaggi ripetibili, riduce gli errori sotto stress e consente di ricavare miglioramenti concreti da ogni test.

Se ne portate via un solo punto: pianificate il ripristino non come „tema di backup“, ma come riavvio end-to-end che includa DNS, identità, segreti, job, monitoring e processi di approvazione. Solo quando i test di failover e le prove di ripristino riescono regolarmente, il recupero in caso di disastro è qualcosa di più della speranza.

Anche per questo argomento sono importanti il Disaster Recovery Runbook e la comunicazione sugli incidenti. L’articolo inquadra questi aspetti in modo chiaro e mostra cosa conta nella pratica quotidiana.