Governance dei backup nella pratica: responsabilità, documentazione e checklist per l'audit

La Governance del backup è la parte della gestione dei backup che in pratica manca più spesso: responsabilità chiare, documentazione tracciabile e controlli ripetibili. Molti team dispongono di job di backup, storage e uno strumento – ma non di una risposta solida alle domande “Chi decide cosa?”, “Come viene verificato?” e “Come dimostriamo in audit che il ripristino funziona davvero?”. Questo contributo interviene proprio su questi punti: con un modello di ruoli praticabile, una struttura documentale snella ma completa e una checklist di audit che potete utilizzare in esercizio – non solo in caso di verifica.

Il focus è volutamente su temi quotidiani per amministratori, system engineer, operatori e fornitori di servizi IT tecnici: cause tipiche dei problemi di backup, prerequisiti per RESTore affidabili, rischi legati a modifiche e migrazioni, passaggi di verifica, attuazione e strategie di rollback. Per la categoria MariaDB trattiamo inoltre punti specifici del database, perché “backup riuscito” lì senza validazione di consistenza e di RESTore dice poco.

Perché la Governance del backup è più di un concetto

Senza governance si crea una condizione pericolosa: i backup girano, i report sono verdi, ma l’organizzazione non è in grado di decidere rapidamente e correttamente in caso di incidente. Il fallimento raramente dipende dallo strumento, ma da lacune nelle responsabilità e nella catena di evidenza:

• Priorità poco chiare: quali sistemi devono essere ripristinati per primi se sono colpiti storage, rete o sistemi di identità?
• Mancata tracciabilità: quale configurazione era valida in quale momento (retention, crittografia, esclusioni, credenziali)?
• Nessuna esercitazione di RESTore affidabile: «Potremmo ripristinare» non è coperto da esecuzioni di test con criteri di successo.
• Rischio in sede di audit: senza documentazione e prove (log, protocolli di test, cronologia delle modifiche) i requisiti su disponibilità, protezione dei dati o conservazione sono difficilmente verificabili.

Qui governance non significa burocrazia, ma affidabilità operativa: le decisioni sono assegnate, i processi sono documentati, i controlli sono ripetibili e i risultati sono archiviati in modo verificabile.

Governance del backup: ruoli, responsabilità e punti decisionali

In pratica la Governance del backup funziona meglio con poche ruoli chiaramente delimitati. Importante: i ruoli sono pacchetti di attività – non devono coincidere con posizioni o persone. Ciò che conta è che ogni compito sia assegnato esattamente una volta in modo univoco.

Modello di ruoli (compatto, operativo)

• Service Owner (responsabilità di sistema/applicativa): definisce il fabbisogno di protezione, RTO/RPO (valori target per i tempi di ripristino e la perdita massima di dati), classificazione dei dati e dipendenze (ad es. Identity, DNS, Storage, Key-Management).
• Backup Owner (responsabilità operativa dei backup): è responsabile delle policy (retention, crittografia, immutabilità), della progettazione dei job, del monitoraggio/alerting, della pianificazione della capacità, dei processi di RESTore e delle evidenze.
• Storage/Plattform Owner: è responsabile delle pRESTazioni, dei meccanismi di snapshot/replica, dei supporti, delle funzionalità WORM/Immutable (Write Once Read Many, archiviazione non modificabile) e dei modelli di accesso.
• Security/Compliance (con funzioni di controllo, non esecutive): definisce i requisiti minimi (ad es. MFA, account admin separati, registrazione), esegue controlli a campione e valuta le deviazioni.

RACI-Matrix come minimo: chi esegue, chi decide, chi deve essere informato?

Una RACI-Matrix (Responsible, Accountable, Consulted, Informed) evita zone grigie. Tipici punti decisionali che dovete assegnare esplicitamente:

• Approvazione/modifica della retention e dei luoghi di conservazione (locale, Offsite, Cloud, Band).
• Definizione della priorità di RESTore (tiering: sistemi Tier-0/1/2).
• Eccezioni (es. „kein tägliches Full“, „keine Offsite-Kopie“): chi approva e come viene documentato il rischio?
• Gestione delle credenziali e delle chiavi (Backup-Admin, Storage-Admin, chiavi di crittografia, accessi Break-Glass).

Insidie: in molti ambienti decide „chiunque lo stia facendo in quel momento“. Questo appare rapido, ma crea rischi di audit e di incidenti, perché le modifiche non sono più tracciabili.

Documentazione che aiuta nell’operatività (e non solo per l’audit)

La documentazione dei backup raramente fallisce per mancanza di strumenti, ma per una portata sbagliata. Troppa documentazione non viene mantenuta, troppo poca è inutile. Un buon obiettivo è: ogni decisione critica è verificabile e ogni RESTore è documentato come processo.

1) Scheda di protezione del sistema per servizio (1–2 pagine, ma completa)

Per ogni sistema rilevante o per ogni soluzione software vicina al processo create una scheda di protezione. Non è un manuale, ma un profilo operativo:

• Contesto business: scopo, tipi di dati (personali, critici per il business), referenti.
• RTO/RPO: valori target, motivati dai requisiti di processo.
• Dipendenze: DNS, AD/LDAP, NTP, Storage, Key-Management, segmenti di rete.
• Metodologia di backup: basata su agent, basata su snapshot, DB-nativa, basata su file; inclusi i meccanismi di consistenza.
• Varianti di RESTore: RESTore di file, RESTore di VM, bare-metal, RESTore DB, point-in-time.
• Frequenza dei test: quali esercitazioni di RESTore, con quale frequenza, criteri di successo.

Perché funziona: in un incidente le discussioni su RTO/RPO arrivano troppo tardi. La scheda di protezione anticipa la decisione e rende visibili le dipendenze che dominano i tempi di RESTore (es. mancanza di accesso al materiale delle chiavi o account admin bloccati).

2) Backup-Policy come documento vivo (versioning, storico delle modifiche)

La Policy è la «costituzione operativa» dei vostri backup. Dovrebbe essere versionata (es. in Git o nel sistema di change management) e coprire almeno:

• Logica di retention: es. GFS (Grandfather-Father-Son: quotidiano/settimanale/mensile), regole speciali per stati mensili/annuali.
• Protezione contro la manomissione: Immutable/WORM, ruoli separati, account admin separati, MFA.

Stolperfalle: le policy esistono, ma nessuno può dimostrare quando sono state modificate o se i sistemi divergono. La governance non richiede perfezione, ma trasparenza: le deviazioni devono essere visibili e valutate.

3) Runbooks: RESTore ist ein Prozess, kein Klick

Un Runbook è una guida passo-passo per attività ripetibili, incluse prerequisiti, verifiche e percorso di fallback. Per i backup sono sensati almeno due Runbooks:

• «Standard-RESTore» (frequente): file, singoli DB/schemi, oggetti VM, stati di configurazione.
• «Disaster-RESTore» (raro, ma critico): ambiente completo, identità, funzioni di base della rete, gestione delle chiavi, cluster di recovery.

Importante: un buon Runbook non contiene solo i passaggi, ma anche validazione (come verifico che funzioni?) e criteri di interruzione (quando fermarsi e procedere all’escalation?).

Insidie tipiche dell’operatività (e come attenuarle)

«Backup riuscito» non significa «RESTore possibile»

Molti strumenti segnalano il successo del job quando i dati sono stati scritti. Questo non dice però nulla sulla leggibilità, completezza o coerenza applicativa. Cause:

• catene difettose o incomplete (incrementali/differenziali),
• metadati mancanti (ACLs, attributi estesi, proprietario),
• snapshot non coerenti (l’applicazione scrive durante lo snapshot),
• backup cifrati senza test del ripristino delle chiavi.

Contromisura: test di RESTore come controllo obbligatorio, con criteri di successo definiti (es. controlli hash, stato di salute dell’applicazione, integrità del DB).

Credential- und Key-Management ist der häufigste «unsichtbare» Single Point of Failure

I backup falliscono spesso in caso reale perché:

• gli account admin di backup sono bloccati durante l’incidente (reazione a ransomware),
• MFA/Conditional Access impediscono l’accesso di emergenza,
• le chiavi di cifratura non sono disponibili o non documentate,
• i segreti si trovano nello stesso vault che dovrebbe essere a sua volta ripristinato.

Regola pratica: per il recovery dovete documentare un Break-Glass-Pfad (accesso di emergenza definito), metterlo in sicurezza tecnica (es. token separati, materiale d’emergenza offline) e testarlo regolarmente.

Retention, conservazione e costi divergono

La retention non riguarda solo «per quanto», ma anche «dove» e «in quale forma». Senza governance si generano effetti tipici: conservazione troppo breve (rischio di audit) o costi non previsti (conservazione troppo lunga su storage costoso). È cruciale una regolamentazione per:

• ripristino a breve termine (veloce, vicino al sistema di produzione),
• stati a medio termine (Offsite, più economici, ma ripristinabili),
• lungo termine (Archivio), con chiara separazione tra Backup vs. Archivio (l’Archivio è spesso immutabile e vincolato allo scopo).

MariaDB-spezifische Governance-Punkte: Konsistenz, Binlogs und Point-in-Time-RESTore

In MariaDB la governance è particolarmente importante, perché intervengono più meccanismi: backup fisici (p. es. Percona XtraBackup), esportazioni logiche (p. es. mysqldump) e Binlogs (Binary Logs, registri delle modifiche a livello di transazione). Senza regole chiare si riesce sì a recuperare dati, ma non un punto di ripristino riproducibile.

Minimo per MariaDB: cosa deve essere documentato?

• Tipo di backup: fisico (ripristino rapido, vicino alla struttura di storage) vs. logico (portabile, più lento).
• Metodo di consistenza: Hot-backup, snapshot con freeze o arRESTo controllato; incl. rischi di corruzione dei dati.
• Strategia Binlog: periodo di conservazione dei Binlog, copia offsite, correlazione con i Full-Backup.
• Processo PITR: Point-in-Time-RESTore (ripristino a un punto temporale) incluso ‚Stop-Time‘ e passaggi di verifica.
• Versioni e compatibilità: versione di MariaDB, storage engine (InnoDB ecc.), versione del tool di backup; rilevante in caso di RESTore su nuova piattaforma.

Controlli operativi comprovati

Questi controlli sono abbastanza semplici da eseguire regolarmente, ma significativi:

• Artefatti di backup presenti? Full-Backup + metadata associati + Binlogs per PITR.
• Lacune nei Binlogs? Una finestra temporale senza Binlogs rende impossibile il PITR.
• Prova di ripristino: ripristino in ambiente di test isolato, quindi controlli di integrità e plausibilità.

Esempio: verificare se i Binlogs sono attivi e per quanto tempo vengono conservati (esempio semplificato, adattare in base alla configurazione):

-- Binlog-Status und relevante Parameter prüfen
SHOW VARIABLES LIKE 'log_bin';
SHOW VARIABLES LIKE 'binlog_format';
SHOW VARIABLES LIKE 'expire_logs_days';
SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';
SHOW MASTER STATUS;

Perché questo funziona: senza Binlog attivi o con un periodo di conservazione troppo breve si può riportare indietro uno stato full, ma non ripristinare fino a poco prima dell’incidente. Quando fallisce: se i Binlog sono attivi ma non vengono salvati offsite in modo coerente o se si generano lacune a causa di errori di storage/replicazione.

Troubleshooting: insidie tipiche di MariaDB nei test di ripristino

• Dipendenze mancanti: L’host di ripristino ha versioni diverse di libc/OpenSSL, opzioni del filesystem differenti o limiti I/O diversi; il ripristino richiede più tempo del previsto.
• Permessi/ACL: la directory dei dati non appartiene correttamente all’utente DB; l’avvio fallisce o si generano problemi successivi.
• Scostamento temporale: deriva dell’orologio (NTP) conduce a una ‚Stop-Time‘ errata nel PITR e complica le evidenze di audit.
• Spazio insufficiente: il ripristino richiede temporaneamente più capacità (decompressione, fase di prepare, file temporanei).

Governance qui significa: questi rischi non sono solo nella testa delle persone, ma sono documentati nei Runbooks – inclusi i criteri di interruzione e i percorsi alternativi (es. RESTore su un volume temporaneo più grande, poi migrazione).

Controlli e prove: cosa dovRESTe verificare regolarmente

La governance si fonda sui controlli. È importante distinguere tra:

• Controlli preventivi (prevengono errori): policy, change management, ruoli, hardening.
• Controlli detective (individuano errori): monitoring, report, campionamenti, test di RESTore.
• Controlli correttivi (risolvono errori): processo di incident, problem management, tracciamento delle azioni.

Monitoring/Alerting: allarmi che davvero aiutano

Un monitoring dei backup funzionante non allerta su “tutto”, ma su ciò che mette a rischio la recuperabilità:

• Fallimento di job o ripetuti “warn” senza ticket.
• mancata copia offsite entro la finestra concordata.
• Immutable/WORM non attivo o policy modificata.
• Tendenze di capacità e crescita (tempo fino al “pieno”), separate per tier di backup.
• Test di RESTore scaduti o falliti.

Insidia comune: molti team monitorano solo i codici di uscita dei job. La governance richiede segnali di „RESTore-Readiness“, cioè indicatori direttamente collegati alla recuperabilità.

Checklist di audit Backup-Governance (utilizzabile operativamente)

La checklist di audit seguente è formulata in modo da poter essere utilizzata internamente come self-assessment. Per ogni punto non dovRESTe limitarevi a “sì/no”, ma documentare anche dove è la prova? (link a ticket, report, repository, archivio log).

A) Organizzazione & responsabilità

• Le responsabilità sono definite (Service Owner, Backup Owner, Security/Compliance, Operator) e aggiornate.
• Esiste una matrice RACI che copre retention, prioritizzazione dei RESTore, autorizzazioni per eccezioni.
• Sono documentati i percorsi di escalation (incl. finestre temporali, handover on-call, Incident-Lead).
• Sono disponibili accessi Break-Glass per il recovery, isolati, protetti e testati.

B) Scope & classificazione

• Inventario: quali sistemi, database, fileshare, piattaforme rientrano nello scope dei backup?
• La classificazione dei dati per servizio è documentata (es. dati personali, riservati, critici).
• RTO/RPO sono definiti per servizio e implementati nei RESTore-Runbooks (non solo “valori desiderati”).

C) Tecnica & controlli di sicurezza

• La cifratura in transito e at REST è implementata; la proprietà/rotazione delle chiavi è documentata.
• Immutable/WORM o meccanismi di protezione equivalenti sono attivi dove richiesto (scenari ransomware).
• I modelli di amministrazione sono separati (Backup-Admin ≠ Domain-Admin); MFA/Conditional Access sono compatibili con le procedure di recovery.
• I log sono protetti da manomissione o centralmente archiviati (per le prove durante un incident).

D) Retention, Aufbewahrung, Offsite

• Il piano di conservazione è documentato e implementato tecnicamente (incl. eccezioni).
• Esiste una copia offsite in un contesto di sicurezza separato (altre credenziali/altro dominio/altra storage-policy).
• Il percorso di ripristino dalla copia offsite è testato (non solo „potremmo“).
• È presente la pianificazione della capacità (crescita, modifiche alle politiche di conservazione, decisioni su costi/tiering).

E) RESTore-Tests & Validierung

• Esiste un piano di test (frequenza per Tier) che copre le varianti di ripristino (file, VM, DB, PITR).
• I criteri di successo sono definiti (es. avviabilità, controlli di integrità, campionamenti, baseline delle pRESTazioni).
• I verbali di test sono archiviati e tracciabili (data, versioni, risultato, discrepanze, azioni).
• I test falliti generano ticket e azioni correttive (non vengono „ignorati fino all’audit“).

F) MariaDB-spezifisch (wenn im Scope)

• Tipo di backup e metodo di consistenza sono documentati (fisico/logico, Hot/Snapshot/Stop).
• La strategia dei binlog è definita (retention, offsite, rilevamento delle lacune).
• PITR è documentato come runbook e testato almeno a campione.
• L’ambiente di ripristino può riprodurre versione/compatibilità (dipendenze, file system, risorse).

Umsetzung in 30 Tagen: pragmatischer Fahrplan

Se partite da zero, aiuta un piano breve e realistico. L’obiettivo non è la completezza, ma un primo ciclo di governance con evidenze misurabili.

Woche 1: Scope, Rollen, kritische Services

• Stilare l’inventario e il tiering (Tier 0–2).
• Assegnare Service Owner e Backup Owner per ogni sistema Tier-0/1.
• Definire RTO/RPO in modo approssimativo (prima versione), raccogliere dipendenze.

Woche 2: Policy-MVP und Runbook-Entwurf

• Redigere e versionare una backup policy minima (retention, offsite, crittografia, immutability, monitoring).
• Creare una bozza dei runbook „Standard-RESTore“ e „Disaster-RESTore“.
• Definire il percorso Break-Glass e sottoporlo a una revisione di sicurezza.

Woche 3: Kontrollen aktivieren und Nachweise sammeln

• Affinare la logica di monitoring e escalation (segnali di RESTore-Readiness).
• Eseguire e protocollare le prime prove di ripristino per Tier 0/1.
• MariaDB: pianificare un controllo dei binlog e un test PITR in ambiente isolato.

Woche 4: Audit-Checkliste als Betriebsroutine etablieren

• Eseguire un’autovalutazione rispetto alla checklist, prioritizzare le deviazioni.
• Creare ticket/azioni, assegnare responsabili, stabilire scadenze.
• Appuntamento periodico: round di governance mensile (breve), esercitazione di ripristino trimestrale (più estesa).

Rückfallstrategie: Was tun, wenn Governance „zu schwer“ wird?

In alcuni ambienti le risorse sono scarse o le responsabilità politicamente complesse. In questi casi aiuta una strategia di fallback che riduca comunque i rischi maggiori:

• Ridurre a Tier-0/1: Avviare solo con il 10–20% dei sistemi più critici, ma farlo bene (runbook, test, evidenze).
• Documentazione come scheda sintetica: Non un romanzo wiki, ma una scheda di protezione + Policy-MVP + due runbook.
• Test di ripristino come „Gate“: Autorizzare modifiche a retention/offsite/chiavi solo dopo un test di ripristino riuscito nello scenario corrispondente.
• Permettere deviazioni, ma renderle visibili: Le eccezioni sono consentite se rischio e approvazione sono documentati.

Non è una governance perfetta, ma una che consente decisioni migliori durante un incidente ed è difendibile in sede di audit.

Conclusione: la governance dei backup è la via più breve per un ripristino affidabile

La governance dei backup è spesso considerata un „extra“. In esercizio è ciò che trasforma i backup in un sistema di recovery controllabile, verificabile e utilizzabile in caso di necessità. Quando i ruoli sono chiari, la documentazione concisa ma completa e i test di RESTore sono istituiti come controllo, i rischi tipici diminuiscono sensibilmente: prioritarizzazione errata, chiavi mancanti, lacune non rilevate nei Binlog e „job verdi“ privi di ripristinabilità.

Se dovesse portare via un solo punto da questo contributo: pianifichi la validazione del RESTore come routine operativa ricorrente – incluse le relative evidenze. Tutto il RESTo (Retention, Offsite, Immutable, MariaDB-PITR) diventa affidabile nella pratica quotidiana solo grazie a ciò.

Per questo tema sono importanti anche le responsabilità sui backup. Il contributo inquadra questi aspetti in modo comprensibile e mostra cosa conta nella pratica quotidiana.