Strategie di replica e backup

Breve riepilogo

La strategia dei dati è affidabile su tre pilastri: bacap, replica, ripristino. La replica riduce RTO (tempo di ripristino), il backup garantisce RPO (perdita di dati) e protegge dagli errori logici/crittografati. I principi di base sono 3-2-1-1-0 (3 copie, 2 tipi di supporti, 1 offsite, 1 invariato, 0 errori di verifica), test regolari del DR e immutabilità dei set critici.

Termini e obiettivi

RPO - quanti dati possono essere persi (ad esempio 5 minuti).
RTO - quanto tempo è consentito ripristinare (ad esempio, 15 minuti).
PITR (Point-in-Time Recovery) - Ripristino X con la replica dei registri.
SLO dati è un contratto di livello di servizio per RPO/RTO e il successo delle attività di Becap.

Esempio di matrice:

Classe dati	RPO	RTO	Note
Transazioni/portafoglio	≤ 1-5 min	5-15 min	Registri + replica sincrona kernel
Report/PII	≤ 1 h	≤ 1 h	WORM/immutability, archivi
Logi/eventi crudi	≤ 24 ore	≤ 4 ore	Oggetto, lifecycle

Modelli di resilienza e replica

Varianti topologia

Active-Passive (caldo/caldo/freddo) è più semplice, prevedibile.
Active-Active: elevata disponibilità, ma più complessa è il conflitto-risolutezza e la consistenza.
Multi-Zone/Region/Cloud - bilancia ritardi e costi egress.

Sincrone vs asincrone

Sincron: RPO≈0, latency, distanza limitata.
Asinhon: vicino a zero RTO con RPO ridotto (minuti), regge regioni/nuvole.
Ibrido: sincrone all'interno della zona, asincrone alla regione remota.

Replica del backup

La replica porta via errori/rimozione dopo l'origine. Bacap è una copia off-path con versioning, controlli e isolamento.

Criteri 3-2-1-1-0 e immutabilità

3 copie (prode + backup locale + off).
2 tipi di supporti (unità/NAS/oggetto/nastro).
1 offsite (altro sito/cloud/nastro).
1 copia invariabile (WORM: Object Lock, immutabile snapshots/nastro).
0 errori: controllo regolare dell'integrazione (checksum/verify/restore-test).

Pratica:

Includere la versioning e l'Object Lock (Compliance/Governance) per un oggetto con bacap critici.
Per NAS/blocchi, gli snapshots immutabili con retino e proibizione della rimozione entro la scadenza.

Tipi di backup e pianificazione

Full è una copia completa.
Incremential è solo un cambiamento dal passato del backup.
Differential - Modifiche dall'ultimo completo.
Forever-incremental con piano GFS (Grandfather-Father-Son): invertiti diurni, settimanali e mensili «sintetici completi».

Raccomandazione (esempio):

Prod BD: full (o full sintetico) giornaliero, incantesimi/registri ogni 5-15 minuti (PITR).
File server: full settimanale, incremental giornaliero, archivi mensili.
Oggetto: lifecycle + versione; - in una classe di archiviazione/nastro archiviata.

Applicazioni e database: pratiche PITR

PostgreSQL

Abilita backup e backup WAL PITR tramite «restore _ command».
Strumenti: «pgBackRest», «wal-g» (oggetto), «pg _ basebackup» per i completi.
Separa i volumi dati e WAL scrivere WAL su veloce NVMe con PLP.

MySQL/MariaDB

Binary log per PITR completi attraverso «Percona XtraBackup» (hot backup).
Replica GTID per DR - asincrone nella regione/cloud.

MongoDB

Oplog per PITR; frammenti a livello di storage + «mongodump» per le copie logiche.
Prova la consistenza della replica prima del backap.

Redis/Cash

A parte il backap: tenere RDB/AOF + offsite; ripristinare come warm-cache o da una fonte di verità.

Kubernets e contenitori

etcd cluster è un obiettivo critico separato (snapshot frequenti, offsite).
Velero: bacap di manifesti/risorse + CSI-snapshot/PV; archiviazione in un bustino compatibile S3 (con Object Lock).
Premiazioni Stateful: app-consistent snapshot (pre/post hooks), altrimenti crash-consistent.
Versioning degli oggetti (modelli/media) a livello di bustette.

Virtualizzazione e file server

VM-slot - Utilizza CBT (Changed Block Tracking), memorizza offsite, effettua periodicamente guest-aware quiesce (VSS per Windows).
File server (NAS) - Snap + repliche e test di restore a valanga regolari (campionamento dei file).

Protezione dei backup

Crittografia a riposo (LUKS/ZFS/cloud KMS/Vault) e in trasferimento (TLS/mTLS).
Gestione delle chiavi: singoli ruoli, dual-control, rotazione, memorizzazione offline delle chiavi guidate.
Isolamento: account backap senza diritti di rimozione di copie immutabili reti separate/VLAN.
Resistenza ransomware: immutabile, air-gap (nastri/account isolato/ab).
Controllo: registro delle operazioni di backap, avvisi di rimozione/riduzione del retensh.

Pianificazione delle finestre e della larghezza di banda

Backup window vs: trottling I/O/rete, deduplicazione, compressione.
Rete: invasi ogni N minuti, singoli canali/VPN, repliche notturne o costantemente con QoS.
Change Block Tracking/CDC per ridurre il traffico.
Grandi basi: flusso parallelo/streaming, multiparto multicanale nell'oggetto.

Monitoraggio, metriche e SLO

Le metriche:

Successo delle attività di backup/replica (%), durata, velocità, registro (WAL/binlog/oplog).
Spazio di archiviazione dei backup, coefficiente di deducibilità, altri costi.
Tempo e successo dei test di recupero.

SLO (esempio):

Il successo dei backup è stato di 99. 9 %/30 giorni.
Il RPO è stato rispettato per il 99% del tempo.
RTO (test restore) 15 minuti per il portafoglio, 1 ora per il report.
DR-drill mensile: 100% script regolamentari completati.

Alert:

Backup saltato/non riuscito, PITR> soglia, calo della deduplicazione, mancanza di spazio, modifica della retensica, assenza di test-restore recenti.

Esercitazione DR e verifica dei ripristini

Tabelle (table-top) - Coordinare ruoli, contatti, comunicazioni.
Tecnica: ripristino in sabbia, misurazione RTO, confronto degli importi/dati.
Black-Start: ripristino completo del cluster nude e pulito.
Directory dati - Le fasi di ripristino predefinite (runbooks) per ogni classe di sistema.
Automatico: restore «canaresco» periodico e compressione degli importi di controllo.

Modelli pratici

1) PostgreSQL (pgBackRest + archivio WAL nell'oggetto)

ini
[global]
repo1-type=s3 repo1-path=/pgbackups repo1-s3-endpoint=minio. local:9000 repo1-s3-bucket=pg-wal repo1-s3-key=ACCESSKEY repo1-s3-key-secret=SECRET repo1-retention-full=8 start-fast=y compress-type=zst

2) wal-g (ENV esempio)

bash export WALG_S3_PREFIX=s3://pg-wal/prod export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export WALG_COMPRESSION_METHOD=zstd

3) Velero (K8s - oggetto + immutabilità del baccalà)

yaml apiVersion: velero. io/v1 kind: BackupStorageLocation metadata: { name: default, namespace: velero }
spec:
provider: aws objectStorage:
bucket: k8s-backups config:
s3Url: https://minio. example s3ForcePathStyle: "true"
publicUrl: https://minio. example

4) Criterio Object Lock (esempio «mc»)

bash mc version enable my/backups mc retention set --default COMPLIANCE 365d my/backups

5) Programma GFS di esempio (concept)

Daily: ogni 15 min (riviste), full sintetico diurno.
Week - uno «completo» (sintetico), conservare 8 settimane.
Monthly: completo, conservare 12-24 mesi (archivio/nastro).

Assegno foglio di implementazione

Definite le classi di dati, i proprietari, RPO/RTO/SLO.
I modelli di replica (sync/async) e topologia (AZ/Region/Cloud) sono selezionati.
I backup sono configurati: full/incremental/PITR, pianificazioni, directory.
Immutabilità abilitata (WORM/Object Lock/immutabile snapshots) e offsite/air-gap.
Crittografia e KMS/Vault, ruoli separati e rotazioni delle chiavi.
Monitoraggio: il successo delle attività, i registri, il luogo, il test-restore; Gli alert.
Runbooks ripristino e feelover; contatti, escalation, modelli di comunicazione.
Esercitazioni DR mensili + rapporto, regolazione dei piani.
Budget e FinOps: costo di conservazione/egress, progetto di archiviazione/tiring.

Errori tipici

«Non c'è bisogno di una replica», le cancellazioni logiche e i crittografi andranno in replica.
Nessun test di recupero. Il backap esiste in teoria.
La mancanza di immutabilità e offsite è un unico punto di rischio.
Stesso account/chiave per protesi e bacapi - compromissione = perdita di tutto.
Finestre di bacap troppo lunghe, conflitto con picchi; niente trottling e niente QoS.
PITR senza controllo dei registri.
Ignorare l'app-consistent di snapshot sono volumi «sporchi» da ripristinare.

Specifico per iGaming/Fintech

Portafoglio/nucleo di pagamento: RPO 1-5 min, RTO 15 min; registri (WAL/binlog) in un oggetto con WORM sincrone in zona + regione asincrone.
Report/Regolazione: depositi invariati, restrizioni a lungo termine (anni), integrità verificabile, procedure chiare per il rilascio dei dati ai regolatori.
Loghi/eventi crudi/antifrode: archiviazione a lunga vita a basso costo (oggetto) + lifecycle; indici e vetrine separate.
Picchi (partite/tornei): finestre di backup fuori dai picchi, throttling; Piani DR per il periodo di eventi restore canarini prima delle promozioni.

Totale

La protezione dei dati è una disciplina architettonica: 3-2-1-1-0, versioning e immutabilità, RPO/RTO come SLO, esercitazioni regolari DR e controllo di ripristino «di fatto». Combinare la replica per farmacie e faulovers veloci con backap per errori logici e compromessi. Automatizzate, misurate, documentate, e avrete sempre un percorso di lavoro indietro, anche nel giorno peggiore.