Progettare backup e disaster recovery in base a RPO e RTO

La maggior parte dei programmi di backup viene giudicata il giorno in cui serve, e molti falliscono quel giorno per motivi visibili molto prima: un job che salta un volume senza segnalarlo, un database copiato durante una scrittura, un ripristino che richiede giorni su un collegamento che nessuno ha misurato, oppure backup cifrati dallo stesso attaccante che ha cifrato la produzione.

Questa guida parte da quei numeri, recovery point objective (RPO) e recovery time objective (RTO), e procede verso l'esterno: quante copie conservare, come farne sopravvivere una a un ransomware, come acquisire i database in modo coerente, con quale frequenza dimostrare che i ripristini funzionano, come scrivere i runbook e dove va il denaro.

Partire da RPO e RTO per ogni sistema

L'RPO è la quantità di dati che ci si può permettere di perdere, misurata in tempo. Un RPO di 24 ore significa che un backup notturno è accettabile. Un RPO di 15 minuti significa log shipping continuo, replica o snapshot molto frequenti. L'RTO è il tempo per cui un sistema può restare indisponibile, misurato dal guasto al momento in cui gli utenti tornano a lavorare.

Questi numeri dovrebbero provenire dal responsabile di business di ciascun sistema, non dal solo reparto IT, e dovrebbero essere messi per iscritto. Di solito i sistemi rientrano in pochi livelli:

• Tier 1. Sistemi che generano ricavi e rivolti ai clienti, come elaborazione degli ordini, pagamenti e database principali. Obiettivi tipici: RPO di minuti, RTO da 1 a 4 ore.
• Tier 2. Sistemi interni da cui le persone dipendono ogni giorno, come ERP, condivisioni di file, posta elettronica e ticketing. Obiettivi tipici: RPO da 1 a 4 ore, RTO da 8 a 24 ore.
• Tier 3. Archivi, repliche per la reportistica, ambienti di sviluppo e di test. Obiettivi tipici: RPO di 24 ore, RTO di diversi giorni.
• Ricostruibili. Server stateless costruiti a partire da codice o immagini. Eseguire il backup della configurazione e della pipeline di build, non dei server stessi.

L'RTO comprende tutto: rilevare il guasto, decidere di avviare il ripristino, raggiungere il sistema di backup, predisporre l'hardware, trasferire i dati e validare l'applicazione.

La regola 3-2-1 e la sua estensione moderna

La classica regola 3-2-1 prevede di conservare tre copie dei dati (la produzione più due backup), su due sistemi o supporti di storage diversi, con una copia fuori sede.

Molti team oggi adottano la regola 3-2-1-1-0: una copia è offline o immutabile, e i ripristini vengono verificati con zero errori. I termini aggiuntivi esistono perché chi conduce attacchi ransomware cerca ed elimina i backup raggiungibili prima di cifrare la produzione. Un backup che un account amministratore può cancellare è solo un altro bersaglio.

In pratica oggi “due supporti” indica di solito due sistemi di storage indipendenti piuttosto che disco e nastro. Un'appliance di backup locale più un object storage in un'altra struttura soddisfa il requisito. Due volumi sullo stesso array no, e uno snapshot da solo non è un backup, perché condivide hardware e credenziali con i dati che protegge.

Copie immutabili e isolate contro il ransomware

Una copia immutabile non può essere modificata né eliminata fino alla scadenza del suo periodo di retention, nemmeno da un amministratore. Le opzioni comuni sono l'object storage con blocchi di retention write-once in modalità compliance, le appliance di backup con retention protetta e i supporti scollegati fisicamente.

L'immutabilità serve solo se i controlli circostanti sono all'altezza. Supponi che un attaccante disponga dei diritti di amministratore di dominio in produzione e chiediti che cosa non può ancora toccare:

• Identità separata. La piattaforma di backup usa account propri, non la directory di produzione, con autenticazione a più fattori per ogni accesso amministrativo.
• Retention bloccata. Blocchi di retention che non possono essere accorciati a posteriori, con l'obbligo dell'intervento di due persone per qualsiasi modifica alla policy di retention.
• Separazione della rete. Storage di backup raggiungibile solo dai server di backup, su una rete di gestione separata, senza accesso in ingresso dalle reti degli utenti.
• Profondità della retention. Uno storico sufficiente per risalire a prima dell'infezione. Spesso gli attaccanti restano all'interno di una rete per settimane, quindi 30-90 giorni sono una soglia minima realistica per il livello immutabile.
• Alert sulle anomalie. Alert sui picchi di dati modificati, sui set di backup eliminati e sulle modifiche alla retention, spesso i primi segnali visibili di un attacco.

Pianifica il ripristino dopo un ransomware separatamente da quello dopo un guasto hardware. Dopo un ransomware può essere necessario ripristinare in un ambiente isolato, analizzare i dati, individuare l'ultimo punto integro noto e ricreare le credenziali prima di ricollegare qualsiasi cosa.

Consistenza del database: il punto in cui i backup a livello di file sbagliano

Copiare i file di un database in esecuzione produce di solito un backup che sembra completo e fallisce al ripristino, perché le pagine sono state acquisite in momenti diversi. Usare metodi che il database comprende.

• Strumenti di backup nativi o a caldo. Usare il metodo di backup online supportato dal motore del database, oppure un agente di backup integrato con esso, così che la copia sia consistente a livello transazionale.
• Log shipping per un RPO breve. Combinare backup completi periodici con l'archiviazione continua dei log delle transazioni. Questo consente il point-in-time recovery, incluso il ritorno a un istante immediatamente precedente a un deploy errato o a una modifica malevola.
• Snapshot coerenti a livello applicativo. Se ci si affida a snapshot dello storage o delle VM, mettere prima in quiesce o congelare il database (oppure usare l'integrazione snapshot del motore), così che lo snapshot catturi uno stato coerente.
• La replica non è un backup. Una replica copia fedelmente in pochi secondi cancellazioni, corruzioni e aggiornamenti errati. Mantenerla per la disponibilità e un RTO breve, e conservare backup separati per la recuperabilità.

Misura il tempo di ripristino del database, non solo il tempo di backup. Un ripristino spesso comprende la riapplicazione di ore di log e la ricostruzione degli indici, il che può richiedere diverse volte il tempo del backup. Se un database da 4 TB ha un RTO di 2 ore, verifica se un ripristino può rispettarlo o se serve anche una replica in standby.

Un collegamento da 1 Gbps a pieno carico trasferisce circa 125 MB al secondo, ovvero circa 10 TB al giorno. In pratica l'overhead dei protocolli, la reidratazione della deduplica e la velocità di lettura dello storage limitano spesso il throughput sostenuto al 50-80 percento della velocità di linea.

• Esempio. Ripristinare 20 TB su 1 Gbps con un'efficienza del 70 percento richiede circa 2,9 giorni. Su 10 Gbps richiede circa 7 ore, se lo storage a entrambe le estremità riesce a tenere il passo.
• Prima la copia locale. Un livello di backup locale vicino alla produzione serve rapidamente la maggior parte dei ripristini; i livelli offsite e immutabile servono per i disastri e gli attacchi.
• Ripristinare il sottoinsieme critico. Progettare in modo che i dati Tier 1 possano essere ripristinati per primi e in modo autonomo, senza attendere l'intero dataset.

Un calendario di test di ripristino che dimostri la recuperabilità

Un backup che non è mai stato ripristinato è un'ipotesi. Commisurare l'impegno dei test al tier:

• Ogni giorno. Controlli automatici dello stato dei job e verifica automatica dell'integrità dei file di backup, dove la piattaforma lo consente. Ogni job fallito o saltato apre un ticket.
• Ogni settimana. Ripristinare un campione casuale di file e cartelle da sistemi diversi e confrontarli con i checksum o con l'origine.
• Ogni mese. Ripristinare almeno un database Tier 1 in un ambiente isolato, eseguire un controllo di consistenza e verificare che l'applicazione riesca a leggerlo. Registrare il tempo impiegato.
• Ogni trimestre. Ripristinare dal livello offsite o immutabile uno stack applicativo Tier 1 completo, dipendenze incluse. Confrontare il tempo di ripristino effettivo con l'RTO.
• Ogni anno. Eseguire un'esercitazione completa di disaster recovery, incluso uno scenario ransomware, con le persone che sarebbero davvero reperibili. Includere il processo decisionale, non solo i passaggi tecnici.

Registra ogni test: data, sistema, copia di origine, volume, tempo impiegato e problemi riscontrati. Quando un test supera il suo RTO, trattalo come un incidente con un responsabile e una scadenza.

Runbook che si possono seguire sotto pressione

I ripristini vengono eseguiti di solito da chi è disponibile, a un'ora scomoda, sotto stress. Scrivi i runbook per quella persona: specifici, numerati e testati, con comandi, hostname e output attesi.

• Attivazione e autorità. Quali condizioni avviano il ripristino, chi può dichiarare un disastro e chi deve essere informato.
• Contatti. Responsabili, vendor e fornitori, con numeri di telefono che non dipendano dal funzionamento della posta elettronica.
• Accesso. Come raggiungere la piattaforma di backup e l'ambiente di ripristino se la directory principale, la VPN o il password manager non sono disponibili. Conservare le credenziali di emergenza in una procedura break-glass sigillata e sottoposta ad audit.
• Ordine di ripristino. La sequenza dei sistemi in base alle dipendenze: rete e DNS, identità, database, poi applicazioni.
• Procedure passo per passo. Passaggi esatti per ogni sistema, con il tempo previsto per ciascuno e il modo per verificarne la riuscita.
• Validazione e riconsegna. Come il responsabile di business conferma che il sistema è utilizzabile e che i dati sono sufficientemente aggiornati, e come riprendono le normali attività operative e i backup.

Conserva i runbook in un luogo che sopravviva al disastro che descrivono: una copia stampata, una copia offline cifrata e una copia al di fuori dell'ambiente di produzione.

Compromessi di costo e come gestirli

Ogni riduzione di RPO o RTO costa, e la curva è ripida nella parte bassa. Passare da un RPO di 24 ore a 1 ora costa soprattutto job più frequenti e storage per i log. Avvicinarsi allo zero significa di solito replica continua e un ambiente di standby, con un raddoppio approssimativo dell'infrastruttura per quei sistemi.

• Volume di storage. La profondità della retention moltiplica lo storage. Deduplicazione e compressione aiutano molto per i backup di file e di VM, meno per i dati già compressi o cifrati.
• Livello immutabile. Con la retention bloccata si paga l'intero periodo, anche per i dati che si vorrebbero eliminare prima. Dimensionarlo in modo consapevole.
• Egress e traffico. Alcuni servizi di storage addebitano i dati letti o trasferiti in uscita, il che rende più costosi i ripristini di grandi dimensioni e i test frequenti. Includere nella stima i costi di ripristino, non solo quelli di archiviazione.
• Calcolo di standby. Un warm standby soddisfa RTO brevi ma costa quasi quanto un secondo ambiente di produzione. Un'architettura pilot light replica i dati e provisiona il calcolo durante il ripristino: più economica, ma più lenta.
• Persone e tempo per i test. I test di ripristino e l'aggiornamento dei runbook richiedono ore di lavoro del personale ogni mese. Vanno messi a budget, perché senza di essi il resto della spesa non è dimostrato.

Una semplice regola decisionale: per ogni tier, confrontare la perdita annua attesa con gli obiettivi attuali con il costo annuo dell'architettura che soddisfa obiettivi più stringenti. Se il miglioramento costa meno della perdita che evita, va realizzato. In caso contrario, documentare il rischio accettato e farlo approvare dal responsabile di business.

Checklist di backup e ripristino

• Ogni sistema: RPO, RTO, tier e responsabile per iscritto.
• Dipendenze mappate; l'ordine di ripristino le segue.
• Tre copie per sistema in perimetro, su almeno due sistemi di storage indipendenti, una fuori sede.
• Almeno una copia immutabile o offline, retention di 30 giorni o più per i dati critici.
• Amministrazione dei backup con account separati e MFA. Le modifiche alla retention richiedono due persone.
• Backup su rete isolata, non raggiungibile dalle reti utenti.
• Backup dei database consistenti e specifici per il motore, con archiviazione dei log dove l'RPO è inferiore a qualche ora.
• Throughput di ripristino misurato; il ripristino Tier 1 più grande rientra nel RTO.
• Pianificati e documentati: controllo giornaliero dei job, ripristini settimanali di file, mensili dei database, trimestrali delle applicazioni ed esercitazione completa annuale.
• Runbook numerati, testati, offline e rivisti dopo test o modifiche importanti.
• Alert: job falliti, backup eliminati, modifiche alla retention, picchi di variazione dei dati.
• Costi: storage, traffico, calcolo di standby, tempo del personale. I responsabili approvano i rischi accettati.

Prossimi passi

Inizia compilando RPO, RTO e responsabile per i tuoi dieci sistemi più importanti, poi esegui un ripristino cronometrato del più grande.

Se state realizzando o trasferendo destinazioni di backup, Vonahost fornisce server dedicati con NVMe locale o storage a blocchi di rete fino a 1 PB nella regione che scegliete, e il suo cloud gestito include i backup. Ogni proposta indica configurazione, ubicazione, responsabilità e prezzo mensile in dollari statunitensi, così è chiaro quali parti del piano di ripristino gestite voi e quali il fornitore.