Replicazione a livello di blocco vs backup a livello di file: guida alla scelta per infrastrutture eterogenee

Nelle infrastrutture eterogenee, nella pratica quotidiana di backup e DR (Disaster Recovery, ovvero il riavvio dopo un guasto grave) spesso si scontrano due mondi: la replicazione a livello di blocco e il backup a livello di file. Entrambi suonano come „i dati sono al sicuro“ — ma risolvono problemi differenti. Chi valuta in modo accurato Replicazione a livello di blocco vs. Backup a livello di file evita errori tipici come „la replica è un backup“ o „il backup dei file è sufficiente anche per i database“. Questo contributo fornisce un supporto decisionale per amministratori, ingegneri di sistema e fornitori di servizi IT: con prerequisiti, rischi, passaggi di verifica, implementazione e una strategia di fallback realistica — incluse le insidie specifiche per MariaDB.

Separare i concetti: cosa viene effettivamente protetto?

Replicazione a livello di blocco replica i blocchi di storage (p.es. a livello SAN, iSCSI o array di storage) da un sistema sorgente a una destinazione. Opera al di sotto del file system: al meccanismo di replica non importa se il blocco appartiene al disco di una VM, a un file di dati di MariaDB o a un file di log. Vantaggio: sincronizzazione molto rapida di interi volumi, spesso con RPO (Recovery Point Objective = perdita massima di dati in termini temporali) brevi e RTO (Recovery Time Objective = tempo fino al ripristino dell’operatività) rapidi.

Backup a livello di file salva file e strutture di directory (p.es. tramite agenti, SMB/NFS, rsync o software di backup), spesso con versioning e retention. Vantaggio: ripristino mirato di singoli file, migliore controllo delle versioni e spesso migliore integrazione con concetti immutable/air-gap (protezione contro manipolazioni successive).

Importante: entrambi gli approcci possono utilizzare snapshot. Un snapshot è un’istantanea temporale (generalmente copy-on-write) di un volume o di un file system. Gli snapshot non sostituiscono i backup se risiedono sullo stesso storage o possono essere compromessi dallo stesso attacco.

Perché la replica non è automaticamente un backup

La questione centrale non è se i dati siano „doppemente presenti“ da qualche parte, ma se sia possibile tornare in modo affidabile a un momento definito. La replica replica anche gli errori: cancellazioni accidentali, cifratura da ransomware, corruzione logica dei dati o un deployment errato vengono trasferiti in modo affidabile e rapido alla destinazione. Questo è utile per l’alta disponibilità (HA), ma spesso fatale per il ripristino.

Un backup a livello di file con versioni può in molti casi essere efficace proprio qui: è possibile tornare prima del danno, anche se il danno è stato „replicato in modo pulito“. Il prezzo: i backup sono spesso più lenti nel ripristino di sistemi completi, e la consistenza non è garantita nei database senza meccanismi appropriati.

Decisione in base all’obiettivo: HA, DR, archivio, compliance

Nella pratica aiuta una semplice classificazione prima di discutere gli strumenti:

• Alta disponibilità (HA): L’obiettivo è una minima interruzione. La replica a livello di blocco o i meccanismi di clustering sono efficaci qui, perché permettono una commutazione rapida.
• Disaster Recovery (DR): L’obiettivo è il riavvio dopo un guasto di sito o di storage. La replicazione è sensata, ma solo se esiste un punto di consistenza „pulito“ e la possibilità di tornare indietro.
• Backup/RESTore: L’obiettivo è il ripristino anche dopo errori logici o attacchi. Backup a livello di file, repository di oggetti, archiviazione immutabile e copie offsite sono qui centrali.
• Archivio/Retention/Compliance: L’obiettivo è la conservazione a lungo termine, la tracciabilità e la rintracciabilità. Backup a livello di file con indice/metadati e pool di conservazione separati sono nella maggior parte dei casi più adatti.

In ambienti eterogenei (Windows/Linux, VMs/Bare Metal, NAS/SAN, On-Prem/Cloud, stack applicativi differenti) è quasi sempre sensato un approccio combinato: replicazione per il riavvio rapido di sistemi specifici più backup per percorsi di ripristino versionati e auditabili.

Replica a livello di blocco in esercizio: prerequisiti e insidie

La replica a livello di blocco funziona bene quando definite chiaramente le ipotesi infrastrutturali e operative. Prerequisiti tipici:

• Identità & consistenza: Il target deve poter assumere i volumi replicati in uno stato consistente. Senza quiescenza dell’applicazione (breve „congelamento“ degli accessi in scrittura) si rischiano file system o database inconsistenti.
• Rete & latenza: La replicazione è guidata dall’I/O. Banda, RTT (Round-Trip-Time) e perdita di pacchetti determinano RPO e stabilità. La replicazione asincrona tollera la latenza, quella sincrona è sensibile e può aumentare le latenze di scrittura.
• Split-Brain-Schutz: In caso di guasti non devono esistere entrambe le parti che scrivono „attivamente“. Lo Split-Brain (due lati primari attivi) porta quasi sempre a perdita di dati o a scenari di merge complessi.
• Orchestrazione: Il Failover non è solo „montare un volume“. DNS, IPs, Load Balancer, Secrets, certificati, avvii delle applicazioni, dipendenze (es. AD, NTP, Monitoring) devono essere presenti come Runbook o gestiti tramite automazione.

Insidie tipiche in infrastrutture eterogenee:

• Errori di sequenza: I datastore delle VM vengono commutati, ma il database e i server applicativi si avviano in ordine errato. Risultato: ripristino prolungato, stati inconsistenti.
• Dipendenze nascoste: Un server di licenze, un endpoint PKI interno o un collector Syslog centrale mancano nel segmento DR – e le applicazioni si bloccano all’avvio.
• Catene di snapshot: Gli snapshot dello storage in combinazione con la replicazione possono portare a lunghe „catene“; questo rende più difficili i rollback e aumenta l’overhead I/O.
• Replica senza conservazione: Non esiste un „torna a ieri 02:00“. Allora la replica è solo un modo più rapido per arrivare nello stato sbagliato.

Passaggi di verifica per la replica (Preflight)

Prima di proporre la replica come percorso DR (interno o al cliente), dovRESTe almeno spuntare questi punti di controllo:

• Punto di consistenza definito: Come assicurate la consistenza dell’applicazione (es. flush del DB, freeze del filesystem, snapshot VM con quiesce)?
• Runbook di failover disponibile: Chi fa cosa, in quale ordine, con quali controlli?
• Ritorno (Failback) pianificato: Come riportano i dati indietro senza split-brain o lunghi tempi di inattività?
• Capacità di isolamento: Potete, durante un incidente, fermare la replica per preservare un obiettivo „pulito“?
• Finestra di test: Ci sono prove regolari (almeno parziali), non solo su carta?

Backup a livello di file in produzione: punti di forza, limiti, errori tipici

Il backup a livello di file è spesso lo strato base più realistico in ambienti eterogenei, perché funziona vicino alla piattaforma: Windows-Server, Linux, condivisioni NAS, dati applicativi, directory di configurazione. I principali vantaggi risiedono in versionamento, ripristino selettivo e conservazione.

Gli errori operativi più comuni riguardano più i processi che gli strumenti:

• File aperti e lock: Senza VSS (Volume Shadow Copy Service, servizio di snapshot Windows) o meccanismi equivalenti i file vengono salvati „mentre sono in scrittura“. Questo può renderli inutilizzabili.
• ACL e metadati: NTFS-ACLs, permessi POSIX, xattrs (Extended Attributes) o SMB-Ownership vanno persi se il backup non supporta i metadati. Il ripristino può allora apparire „corretto“, ma i permessi sono compromessi.
• Domini di ripristino troppo grandi: Un singolo job esegue il salvataggio di „tutto“. In caso reale il ripristino richiede troppo tempo, perché mancano priorizzazione e parallelizzazione.
• Nessun test di ripristino: I backup sono considerati „verdi“, ma nessuno ha mai verificato se un ripristino coerente funzioni.

Regola pratica: i backup devono riflettere l’obiettivo di ripristino

Chi necessita di un rapido ripristino del sistema dovrebbe combinare backup a livello di file con backup immagine/VM. Chi ha bisogno rapidamente di singoli file (es. PDF contrattuali cancellati accidentalmente) necessita di versionamento e ricerca/indicizzazione. Chi teme il ransomware necessita di copie immutabili e offsite oltre a credenziali separate.

MariaDB al centro: perché la consistenza del database può ribaltare la decisione

Nella categoria MariaDB la domanda decisiva non di rado è: „Come ripristino uno stato consistente — e fino a che punto posso tornare indietro nel tempo?“ MariaDB è compatibile con MySQL e utilizza tipicamente InnoDB (Storage Engine con log di transazioni). Per i database una copia dei file senza passaggi coordinati è rischiosa: si finiscono per salvare file di dati e log in uno stato intermedio.

La replica a livello di blocco può funzionare per MariaDB se si generano snapshot coerenti a livello applicativo (ossia si sospendono/bufferizzano brevemente le operazioni di scrittura in modo controllato) e si replica lo snapshot. Il backup a livello file può funzionare se è consapevole del database (p. es. dump logici per DB piccoli o backup fisici con uno strumento adeguato).

Tipiche insidie di MariaDB nella replica a livello di blocco

• Consistenza dopo crash non è uguale a consistenza applicativa: Uno snapshot crash-consistente corrisponde a un «blackout». InnoDB può recuperare molto, ma non tutti gli scenari sono puliti e i tempi di recupero sono difficili da pianificare.
• Binary Logs (Binlog): Per il Point-in-Time-Recovery (PITR) servono i Binlogs. La sola replica non fornisce un “ritorno alle 10:17” se alle 10:20 è già stato replicato cifrato.
• Versione/Migrazione: Un upgrade di MariaDB o una migrazione di schema logicamente errata viene replicata. Senza un backup che supporti le versioni non è possibile un rollback pulito.

Tipiche insidie di MariaDB nei backup a livello file

• „Semplicemente copiare /var/lib/mysql“: Questo è spesso inconsistente in esercizio. Anche se a volte «funziona», non è una procedura affidabile.
• Mancanza di Binlogs: Senza Binlogs RESTa solo il «ripristino allo snapshot». Il PITR non è possibile, l’RPO diventa più ampio.
• Manca la prova di RESTore: Un backup è valido solo quando un ripristino su istanza di test, incluso avvio, controlli e verifica applicativa, riesce in modo riproducibile.

Matrice decisionale: quando quale procedura (o entrambe)?

Per l’operatività quotidiana aiuta una matrice pragmatica. Non teoria, ma logica operativa:

• RTO molto basso (minuti): replica a livello di blocco o replica della VM + orchestrazione. Solo file-level di solito è troppo lento per il ripristino completo del sistema.
• RPO molto basso (secondi fino a pochi minuti): la replica è efficace, ma sensata solo con un «cuscinetto temporale» (retention degli snapshot) o un backup separato; altrimenti si replica anche il danno.
• Molti piccoli casi di RESTore (file utente): backup a livello file con versioning, indice e ripristino corretto dei permessi (ACLs/xattrs).
• Alto rischio ransomware: backup file-level/repository con storage immutabile, account separati e copia offline/offsite. La replica può integrare, ma non è una protezione se replica senza limiti e cifra anch’essa i dati.
• Eterogeneo, molte piattaforme: file-level come strato di base; replica mirata a pochi workload critici (p. es. VM del database centrale) e solo con procedure di test e rollback.
• MariaDB con requisito PITR: backup fisico + Binlogs (PITR) o un altro procedimento basato sul transaction log. La replica può fornire lo stato di base, ma non sostituisce il ripristino point-in-time.

Attuazione pratica: punti di controllo che dovRESTe documentare

Indipendentemente dal prodotto i seguenti artefatti sono decisivi. Se mancano, la soluzione in caso di incidente spesso non è riproducibile:

• Inventario di sistema: Quali Volumes/Shares contengono quali dati (Applikation, DB, Logs, Uploads, Konfig)?
• Classe di protezione per workload: Obiettivo RPO/RTO, conservazione, crittografia, offsite.
• Dipendenze: DNS, identità (AD/LDAP), NTP, certificati, segreti, monitoring, percorsi centralizzati di storage/rete.
• Runbooks: Failover, RESTore, Failback, Stop-the-Bleed (sospendere la replica), punti di comunicazione e di approvazione.

Lista di controllo: test minimo di ripristino (tecnicamente affidabile)

Un test di ripristino non deve essere un esercizio completo, ma richiede criteri di successo chiari:

• Integrità: somme di controllo/hash o confronti campionari di file (per backup a livello file).
• Avvio/Boot: VM/Host si avvia, servizi in esecuzione, log plausibili.
• Verifica dell’applicazione: Per MariaDB, p.es. connessione, query semplici, consistenza delle tabelle.
• Tempo: Tempo di RESTore misurato (reale, non stimato).
• Documentazione: Cosa è stato diverso dal previsto? Quale dipendenza mancava?

MariaDB-How-to: Backup + Binlog-PITR come livello di base affidabile

Per MariaDB un approccio consolidato è: backup fisico completo regolare più salvataggio continuo/periodico dei binlog. In questo modo potete tornare a un punto di backup completo e poi riavvolgere fino a poco prima dell’errore (PITR). In pratica viene spesso utilizzato Percona XtraBackup (hot-backup fisico per InnoDB). Questo non è un „interno del framework“, ma artigianato operativo: backup consistente, passi di RESTore pianificabili.

Esempio di flusso (Linux, generico; adattare percorsi/utenti). Questo mostra volutamente la struttura – in produzione dovete conservare le credenziali in modo sicuro (p.es. in una my.cnf accessibile solo a root, in Vault, o in segreti dell’agente di backup) e impostare i permessi correttamente.

1) Backup completo con XtraBackup (fisico, consistente)

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

BACKUP_BASE="/backup/mariadb"
TS="$(date +%F_%H%M%S)"
TARGET="$BACKUP_BASE/full_$TS"

mkdir -p "$TARGET"

# Hinweis: Zugangsdaten nicht im Klartext im Skript lassen.
# Nutzen Sie z. B. eine geschützte my.cnf unter /root/.my.cnf

xtrabackup --backup --target-dir="$TARGET"

# Prepare-Schritt macht das Backup RESTorefähig (Redo-Logs anwenden)
xtrabackup --prepare --target-dir="$TARGET"

# Optional: Integritätsmarker
echo "$TS" > "$TARGET/backup.completed"

2) Binlogs sichern (Grundlage für Point-in-Time-Recovery)

Perché il PITR funzioni, i binlog devono essere attivati e copiati regolarmente in una destinazione separata e versionata. I binlog sono i registri continui delle modifiche (registro delle transazioni/statement), con i quali è possibile riprodurre le modifiche dopo un backup completo.

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

BINLOG_DIR="/var/lib/mysql"
ARCHIVE_DIR="/backup/mariadb/binlogs"

mkdir -p "$ARCHIVE_DIR"

# Alle aktuellen Binlogs auflisten
mysql -N -e "SHOW BINARY LOGS;" | awk '{print $1}' | while read -r f; do
  src="$BINLOG_DIR/$f"
  if [[ -f "$src" ]]; then
    # Kopie mit Metadaten, aber ohne Überschreiben (Versionierung im Repo wäre noch besser)
    cp -n "$src" "$ARCHIVE_DIR/" || true
  fi
done

# Optional: Binlog-Rotation anstoßen (damit ein „abgeschlossener“ Log zum Archiv wandert)
mysql -e "FLUSH BINARY LOGS;"

3) Ripristino + PITR (concetto e passaggi di verifica)

Un PITR è valido solo quanto il vostro test. Durante il RESTore si applica prima il backup completo, si avvia MariaDB in un ambiente controllato e poi si riproducono i binlog fino a un momento definito o fino a una posizione specifica. Passaggi di verifica tipici: avvio senza cicli di crash-recovery, controlli di plausibilità sui dati applicativi, confronto con l’ultima transazione attesa.

Importante per la decisione «replicazione vs. backup»: questo viaggio temporale lo ottenete con la sola replicazione a livello di blocco solo se anche sul lato di replica disponete di versioning/retention degli snapshot e riuscite a isolare abbastanza rapidamente in caso d’incidente. Nella pratica un repository di backup separato è spesso lo strato di base più robusto.

Ransomware-Realität: Was in beiden Modellen schiefgeht

Il ransomware non è più un caso speciale, ma un criterio di progettazione. Per entrambi gli approcci vale:

• Replicazione: i dati cifrati si replicano rapidamente. Senza replicazione ritardata, retention degli snapshot sulla destinazione e un processo di „stop“ durante l’incidente, l’obiettivo DR può diventare inutilizzabile.
• Backup a livello di file: i backup possono essere cancellati o cifrati se gli attaccanti ottengono accesso alle credenziali di backup o al repository. Immutable Storage (WORM/immutabilità), account separati e copie offline/offsite sono determinanti.

Uno schema pratico è: replicazione per disponibilità, backup per recuperabilità. A questo si aggiunge un Incident-Runbook „Stop-the-bleed“: fermare la replicazione, interrompere i job di backup, ruotare le credenziali, creare una finestra per la forense e poi ripristinare selettivamente da un punto pulito nel tempo.

Rückfallstrategie: Was tun, wenn der geplante Pfad scheitert?

Strategia di fallback significa: prevedere il momento in cui un RESTore fallisce o un Failover svela dipendenze inaspettate. Un piano solido prevede livelli:

• Livello 1: Ripartenza sullo stato replicato (rapida, ma rimane il rischio di errori logici).
• Livello 2: Rollback allo snapshot di destinazione (se è presente retention e lo snapshot è precedente all’incidente).
• Livello 3: Ripristino dal repository di backup (versionato/immutable, indipendente dallo storage replicato).
• Livello 4: Ripristino parziale (es. MariaDB da PITR, file da versioni, server applicativi ricreati da template/IaC).

Affinché non RESTi teoria, definite in anticipo: chi decide il livello, quale priorità dati si applica (es. prima MariaDB, poi upload, poi reporting) e quale downtime massimo è accettabile. Soprattutto in ambienti misti un RESTore „tutto o niente“ è raramente ottimale.

Empfehlung für heterogene Infrastruktur: Ein pragmatischer Zielaufbau

Se state ristrutturando o consolidando un setup esistente, questo obiettivo è nella pratica gestibile:

• Strato base: backup a livello di file/repository con versioning, retention chiara e copia offsite (3-2-1 come linea guida: 3 copie, 2 supporti, 1 offsite).
• Per sistemi critici: replicazione a livello di blocco (o replicazione VM) con metodo di consistenza definito e retention degli snapshot sulla destinazione.
• Per MariaDB: backup fisico completo + archiviazione dei binlog per PITR, oltre a prove di RESTore regolari su istanza di test.
• Operazioni: monitoring/alerting sul successo dei job, durata, volume di dati, livello di riempimento del repository e test di RESTore — non solo ‚job verde‘.

Questo riduce la pressione sui test DR: non è necessario ricostruire ogni sistema interamente dal backup quando la replica permette di proseguire rapidamente il lavoro. Allo stesso tempo RESTa possibile tornare a un punto temporale pulito se il danno logico è già stato replicato.

Conclusione: Replica a livello di blocco vs. Backup a livello di file non è una questione di fede

La decisione Replica a livello di blocco vs. Backup a livello di file viene presa al meglio, in infrastrutture eterogenee, in base agli obiettivi operativi: la replica è una leva potente per RTO brevi e failover rapidi, ma senza versionamento e capacità di isolamento si replica anche il danno. I backup a livello di file forniscono versioni, ripristini selettivi e una retention migliore – ma falliscono se la consistenza (in particolare con MariaDB) e i test di RESTore non vengono presi sul serio.

Se dovete portar via un’unica linea guida pratica: Replica per la disponibilità, backup per la recuperabilità – e testare entrambi regolarmente, con un runbook chiaro „Stop-the-bleed“ e una strategia di fallback graduata.

Per questo argomento sono importanti anche i backup immutabili e la protezione da ransomware. Il contributo contestualizza questi aspetti in modo chiaro e mostra su cosa bisogna concentrarsi nella pratica quotidiana.