Implementare in modo pragmatico i piani di retention: GFS, intervalli incrementali e obblighi di legge

I piani di retention sono un obbligo operativo: stabiliscono in modo vincolante quali backup, per quanto tempo, dove e in quale formato vengono conservati. La parola chiave focale „piani di retention“ compare subito all’inizio, perché una corretta pianificazione di queste regole di conservazione ha impatti immediati sul budget di storage, sulla capacità di ripristino e sulla compliance. Questo contributo è rivolto ad amministratori, system engineers, operatori e fornitori di servizi tecnici e illustra la rotazione GFS, gli intervalli incrementali, le specificità di MariaDB nonché strategie pratiche di verifica e rollback.

Perché un piano di retention è più di «cancellare i backup più vecchi»

Un piano di retention è una regola operativa vincolante basata su RTO (Recovery Time Objective) e RPO (Recovery Point Objective). L’RTO descrive il tempo di inattività massimo tollerabile, l’RPO l’intervallo massimo di perdita di dati accettabile. Entrambi i parametri guidano la scelta tra backup completi e incrementali, le durate di conservazione, gli intervalli di verifica e le routine di reporting.

Per l’esercizio operativo ciò significa: pianificazione dello storage vincolante, cicli di cancellazione automatizzati con modalità dry‑run, responsabilità documentate e percorsi di rollback testati nel caso in cui cancellazioni o test di ripristino vadano a vuoto. In assenza di questi accordi operativi si rischiano errori di cancellazione non rilevati, lacune di compliance o tempi di RESTore imprevedibili.

Operationalizzare i piani di retention: ruoli, processi, governance

Un piano di retention è affidabile solo se, oltre alla tecnologia, sono definiti anche processi e responsabilità. Operationalizzare significa, in concreto:

• Definire responsabilità: chi autorizza eccezioni di conservazione? Chi valida i test di RESTore?
• Gestione delle modifiche: ogni variazione del piano di retention passa per review, test in staging e rilascio (change‑ticket).
• Audit‑trail: ogni cancellazione, ogni spostamento in quarantena o ogni ripristino è registrato e dimostrabile.

Perché è importante: la sola tecnologia può applicare regole di cancellazione errate senza controllo umano. La governance impedisce che termini formali di conservazione vengano tecnicamente violati.

Strategia GFS (Grandfather‑Father‑Son) nella pratica

GFS è uno schema di rotazione consolidato con livelli annuale, mensile e settimanale. Obiettivo: archiviazione a lungo termine con accesso rapido per RESTore a breve termine. I livelli (Grandfather=annuale, Father=mensile, Son=settimanale/giornaliero) si ordinano in base alla frequenza di accesso e alla durata di conservazione.

Indicazioni pratiche:

• Usare convenzioni di denominazione univoche (es. /backup/{env}/{year}/{month}/{week}) e file di metadati con UUID, timestamp di creazione, checksums e versione dello strumento.
• Dimensionare la capacità con assunti di crescita conservativi e pool di riserva.
• Documentare il percorso di RESTore per ogni livello GFS: quanti passaggi, durata prevista e dipendenze (es. binlogs per il ripristino).

Intervalli incrementali: lunghezza della catena, RPO e integrità

I backup incrementali risparmiano spazio ma aumentano la complessità del ripristino. La lunghezza della catena (numero di step incrementali consecutivi) è un parametro centrale: più lunga è la catena, più è vulnerabile a errori intermedi.

Raccomandazione: limitare le lunghezze di catena (es. massimo 7–14 step) e imporre successivamente un backup completo. Integrare controlli di integrità immediati (checksums, verifica di xtrabackup_info) dopo ogni salvataggio. Una catena troppo lunga aumenta la probabilità che un singolo errore renda inutilizzabile l’intera catena.

Pianificare gli intervalli in modo concreto

Un esempio robusto per tassi di modifica medi:

• Backup incrementali giornalieri, conservazione 14 Tage (ripristino rapido per dati recenti).
• Backup completo settimanale o backup differenziale, conservazione 4 Wochen.
• Backup completo mensile (Father), conservazione 12 Monate.
• Backup completo annuale (Grandfather), conservazione 7–10 Jahre per dati rilevanti ai fini di legge.

MariaDB‑Spezifika: Binlogs, XtraBackup, LVM‑Snapshots und PITR

Per MariaDB i Binlogs (Binary Logs) sono centrali: registrano tutti i comandi di modifica e consentono il Point‑In‑Time‑Recovery (PITR) oltre alla replicazione. Percona XtraBackup è uno strumento consolidato per hot‑backup di database basati su InnoDB. Gli snapshot LVM possono servire, su grandi filesystem, come base per backup consistenti perché catturano per un breve periodo uno stato coerente del filesystem.

Binlog‑Management: praktische Befehle, Konfiguration und Fallstricke

Controlli SQL importanti per i Binlog:

# Liste der vorhandenen Binlog‑Dateien und Größen
mysql -e "SHOW BINARY LOGS;"
# Aktuelle Position und Dateiname
mysql -e "SHOW MASTER STATUS;"
# Prüfen, wie weit Replikate sind
mysql -e "SHOW SLAVE STATUSG"

Esempio di configurazione in my.cnf (beispielhaft):

# /etc/my.cnf.d/backup.cnf
[mysqld]
log_bin = /var/lib/mysql/mysql-bin
binlog_format = ROW
server_id = 42
# Automatisches Ablaufen von Binlogs nach 30 Tagen
binlog_expire_logs_seconds = 2592000

Quando ciò fallisce: un’impostazione aggressiva di binlog_expire può rendere impossibile il PITR se è necessario ripristinare oltre il periodo configurato. Analogamente, slave di replicazione asincrona con lag significativo possono far sì che i binlog necessari siano già stati eliminati. Per questo sono indispensabili allineamenti con l’architettura di replicazione e gli scenari di RESTore.

XtraBackup: Ablauf, Prüfungen und typische Fehler

XtraBackup crea un backup incrementale/completato incluso i metadati. I controlli decisivi sono:

• Verificare i metadati: xtrabackup_info e xtrabackup_checkpoints devono essere presenti e logicamente consistenti.
• Verificare l’integrità: xtrabackup –check e un test‑RESTore isolato sono lo standard.
• Controllare lo strato di trasporto: errori nella copia (p.es. rsync, scp, object upload) portano a backup inconsistenti.

Esempio: creare un backup completo e aggiungere incrementali (semplificato):

# Vollbackup
xtrabackup --backup --target-dir=/backup/full/2026-07-01 --user=backup --password=secret
# Inkrementelles Backup
xtrabackup --backup --target-dir=/backup/inc/2026-07-02 --incremental-basedir=/backup/full/2026-07-01 --user=backup --password=secret

Preparazione (prepare) e RESTore (passi semplificati):

# Prepare (apply logs)
xtrabackup --prepare --target-dir=/backup/full/2026-07-01
# Kopieren/RESTore in Data‑Directory (in Wartungsfenster)
systemctl stop mariadb
rsync -a /backup/full/2026-07-01/ /var/lib/mysql/
chown -R mysql:mysql /var/lib/mysql
systemctl start mariadb

Se il prepare fallisce (p.es. per parti incrementali mancanti), il ripristino è possibile solo fino all’ultimo punto integro. Pianificate quindi backup completi regolari e, oltre a questi, test‑RESTore in un ambiente isolato.

Binlog‑Wiedereinspielung mit mysqlbinlog

Per il PITR si applicano i Binlog fino al punto temporale desiderato. Nota importante: mysqlbinlog genera statement SQL che è opportuno verificare in un ambiente di test.

# Binlog bis zu einem Zeitpunkt erzeugen
mysqlbinlog --stop-datetime="2026-07-02 14:30:00" /var/lib/mysql/mysql-bin.000123 | mysql -u root -p
# Alternativ: aus mehreren Dateien
mysqlbinlog --stop-datetime="2026-07-02 14:30:00" /var/lib/mysql/mysql-bin.00012* | mysql -u root -p

Pericoloso è applicare automaticamente senza verifica: transazioni estese o DDL possono modificare lo stato di produzione. Eseguite mysqlbinlog preferibilmente in un’istanza database isolata e verificate dimensione e tempo di esecuzione previsto.

Automazione: Scheduler, validazione e Dry‑Run

I job automatizzati devono essere idempotenti, tracciabili e sicuri. Cron è ampiamente diffuso; i systemd‑Timer offrono migliore visibilità e RESTart‑Policy. Un esempio di systemd‑timer e service per una validazione giornaliera:

# /etc/systemd/system/backup-validate.service
[Unit]
Description=Backup Validation Service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/validate-backup.sh

# /etc/systemd/system/backup-validate.timer
[Unit]
Description=Run backup validation daily

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

Lo script di validazione dovrebbe definire Exit‑Code (0=OK, 1=Avviso, 2=Errore) e scrivere log strutturati in JSON, in modo che i sistemi di monitoring (p. es. Prometheus Pushgateway, ELK) possano generare alert.

Object Storage e Lifecycle Policies (compatibile S3)

Per la conservazione a lungo termine l’object storage offre vantaggi di costo. Usate regole di lifecycle per spostare gli oggetti in tier simili a Glacier. Un esempio di Lifecycle (JSON) per regole di bucket compatibili S3:

{
  "Rules": [
    {
      "ID": "move-to-cold",
      "Filter": {"Prefix": "backup/old/"},
      "Status": "Enabled",
      "Transitions": [{"Days": 30, "StorageClass": "GLACIER"}],
      "Expiration": {"Days": 3650}
    }
  ]
}

Importante: abilitate Object Lock (WORM) solo per i dati che devono essere immutabili per obbligo legale. Le regole di lifecycle non devono cancellare automaticamente copie rilevanti dal punto di vista legale senza approvazione umana.

Analisi dei rischi: Ransomware, corruzione dei dati ed errori degli operatori

I piani di retention devono anticipare scenari di rischio. Il ransomware spesso tenta di crittografare o cancellare tutte le copie. Misure consigliate:

• Storage immutabile o Object Lock per i backup critici.
• Account amministrativi separati per i sistemi di backup, MFA e reti ristrette per gli accessi di backup.
• Bucket di quarantena e cancellazione ritardata (es. 7–14 giorni) per intercettare cancellazioni accidentali o malevole.

In caso di corruzione dei dati aiutano i checksum, l’allertamento immediato e la possibilità di accedere a livelli GFS più datati.

Strategia di rollback e Runbook di recovery

Un runbook solido elenca passaggi concreti e testati per un RESTore e un eventuale rollback. Elementi importanti:

1. Valutazione iniziale della situazione: sistemi coinvolti, RTO/RPO, classi di dati interessate.
2. Selezione della fonte di ripristino: backup completo, replica o copia offsite.
3. Ripristino di test in isolamento e verifica dell’integrità (checksum, smoke test dell’applicazione).
4. Ripristino in produzione durante la finestra di manutenzione con piano di comunicazione (notifiche ai stakeholder, informazioni per gli utenti).
5. Audit post-RESTore: confronto dei dataset, controlli di consistenza e documentazione delle lezioni apprese.

Definite livelli decisionali chiari: chi decide in caso di ripristini falliti? Quando si passa a fonti alternative (p. es. replica)?

Test e audit: con quale frequenza e con quali criteri di accettazione?

Frequenza dei test: prove rapide di RESTore (settimanali), esecuzioni complete di RESTore (mensili) e simulazioni di disastro (annuali). I criteri di accettazione devono essere misurabili, p.es. „RESTore completo di uno schema DB in < 4 ore“ oppure „PITR con RPO massimo 15 minuti“. Documentare le deviazioni e le cause.

Insidie tipiche e come evitarle

• Metadati mancanti: conservare xtrabackup_info e checksums insieme ai dati.
• Regole di cancellazione automatiche senza Dry‑Run: introdurre sempre Dry‑Run e una fase di quarantena.
• Lifecycle Policies non testate: testare le migrazioni in un ambiente Staging‑Bucket.
• Cancellazione dei binlog senza confronto con i replicati: verificare il lag di replica e gli SLA prima di eliminare i binlogs.
• Nessuna riserva di capacità: pianificare per i picchi, non solo per i valori medi.

Checklist per l’introduzione di un Retention‑Plan (pratica)

1. Rilevare: quali classi di dati sono rilevanti e quali scadenze legali si applicano?
2. Classificare: definire e documentare RTO/RPO per classe di dati.
3. Progettazione: definire lo schema GFS, gli intervalli incrementali, Storage‑Tiers, Object Lock e la quarantena.
4. Automazione: implementare script idempotenti, Dry‑Run, systemd‑Timer, log strutturati e allarmi.
5. Validazione: introdurre test di RESTore regolari, controlli di integrità e reporting.
6. Documentazione: Retention‑Policy come documento vincolante incl. ruoli e audit‑trail.
7. Review: verifiche periodiche (p.es. semestrali) e aggiornamenti in caso di modifiche dei requisiti legali.

Conclusione: garantire robustezza operativa

I Retention‑Plan collegano compliance, economicità e sicurezza operativa. In pratica significa: GFS per il fabbisogno a lungo termine, catene incrementali limitate per l’efficienza, controlli di integrità automatizzati e prove di RESTore documentate per l’affidabilità. Per MariaDB sono inoltre temi chiave la gestione dei binlog, l’integrità della XtraBackup‑Chain e test PITR regolari. Testare le modifiche in staging, mantenere le operazioni di cancellazione reversibili fino alla verifica finale e gestire il monitoring con allarmi chiari.

Se seguite questi passaggi, il vostro Retention‑Plan non sarà un documento una tantum, ma un processo operativo vivo: automatizzato, verificabile e conforme dal punto di vista legale. In questo modo proteggete i vostri dati e garantite al tempo stesso una conservazione economicamente sostenibile.

Risorse di approfondimento

Link interni ad articoli di approfondimento (p.es. test di backup con Ansible, resilienza contro ransomware, MariaDB PITR) dovrebbero essere inclusi qui, in modo che Runbooks, Playbooks e checklist di audit siano direttamente accessibili.

Retention‑Management: Metadaten, Legal‑Hold und Monitoring

Una parte spesso sottovalutata della retention è il catalogo dei metadati: documenta quali Backup‑Batches appartengono a quali classi di dati, scadenze legali, risultati delle verifiche e chiavi di crittografia. Senza un catalogo affidabile l’automazione delle cancellazioni diventa pericolosa — perché il sistema non può distinguere in modo sicuro quale copia è ancora soggetta a Legal‑Hold o rilevante per una verifica in corso.

Nota architetturale: separare il Metadaten‑Repository dagli Objekt‑Stores. Utilizzare un database piccolo e altamente disponibile (p.es. un singolo schema protetto in MariaDB o un store documentale) con voci versionate. Ogni Backup‑Batch riceve una UUID, uno status (available, quarantined, deleting, deleted), un owner e una legal_hold_flag. Queste informazioni guidano la Löschpipeline.

La cancellazione in due fasi riduce il rischio: 1) impostare un Tombstone e mettere in quarantena (p.es. 7–14 giorni), 2) dopo un Reconcile e un audit riusciti cancellare definitivamente. Questo permette Dry‑Run, interventi manuali e ripristini automatici in caso di errori.

Il monitoraggio operativo dovrebbe fornire metriche misurabili:

• Percentuale di compliance della retention (previsto vs. reale rispetto alle scadenze)
• Numero di Tombstones e età dei Tombstones
• Errori di cancellazione al giorno e tempo fino alla risoluzione manuale
• Discrepanza tra i metadati e lo storage effettivo (reconcile‑rate)

Esempio di query (tabella metadati backups):

-- Backups, die laut Policy bereits gelöscht sein sollten
SELECT id, uuid, created_at, retention_until, status
FROM backups
WHERE retention_until < NOW() AND status != 'deleted';
-- Tombstones älter als 14 Tage
SELECT COUNT(*) FROM backups WHERE status = 'quarantined' AND updated_at < NOW() - INTERVAL 14 DAY;

Altri punti: gestire la gestione delle chiavi (KMS) per i backup cifrati separatamente e con RBAC; introdurre numeri di versione per gli strumenti di backup ed eseguire verifiche di compatibilità durante le migrazioni. Infine: integrare i job di reconcile nel vostro incident‑runbook — notifica automatica più procedura di escalation via pager, se la reconcile‑rate scende sotto una soglia minima.

Per questo argomento sono importanti anche i backup di MariaDB e la retention dei binlog. Il contributo inquadra questi aspetti in modo chiaro e mostra quello che conta nella pratica quotidiana.