Trasferimento file nel disaster recovery: continuità operativa

Il trasferimento file nel disaster recovery mantiene le operazioni attive quando un sito primario si guasta — attraverso la replica cross-region (S3 CRR, Azure GRS), infrastruttura warm standby e runbook di failover documentati. Un file system DR-ready copia continuamente le modifiche in una posizione secondaria entro un RPO di secondi o ore, supporta il failover entro il target RTO ed è stato testato in condizioni realistiche. Il percorso più diretto verso un DR utile: scegli un workload, replicalo in una seconda region, simula un guasto regionale un sabato e misura cosa succede davvero.

Classificare i workload per impatto sul business

Non ogni file system merita la replica hot-hot. Un'analisi di impatto sul business classifica i sistemi in base alla tolleranza ai tempi di inattività e alla perdita di dati:

Tier 0 (mission-critical): elaborazione pagamenti, sistemi clinici. RPO <1 min, RTO <15 min.
Tier 1 (critico): gestione ordini, app rivolte ai clienti. RPO <15 min, RTO <1 ora.
Tier 2 (importante): strumenti interni, reporting. RPO <24 ore, RTO <8 ore.
Tier 3 (standard): materiale formativo, archivi. RPO <1 settimana, RTO <3 giorni.

Il Tier 0 costa 3-10 volte il Tier 3 da replicare. Mappa i sistemi onestamente. La maggior parte delle aziende ha il 5-10% dei sistemi nel Tier 0-1 e dovrebbe concentrare la spesa lì, piuttosto che trattare tutto ugualmente bene.

Topologie di replica

Tre modelli di replica dominano per lo storage file:

Active-passive: il primario accetta le scritture, il secondario riceve la replica. Il failover richiede una promozione. Usato dalla maggior parte delle configurazioni DR regionali.
Active-active: entrambe le region accettano scritture, con risoluzione dei conflitti. Complessità maggiore ma RTO quasi zero. Usato dai sistemi globali.
Backup-based: backup periodico al secondario. RPO più elevato ma più semplice. Usato per il Tier 3.

S3 Cross-Region Replication (CRR) implementa l'active-passive con RPO inferiore al minuto. S3 Multi-Region Access Points aggiunge il routing di failover. Per l'active-active, DynamoDB Global Tables e CockroachDB gestiscono i database; per i file, rclone in entrambe le direzioni con tag di risoluzione conflitti è un approccio fai-da-te.

Scegliere la region secondaria

Primario e secondario devono guastarsi indipendentemente. Regole pratiche:

Region geografica diversa (eu-west-1 → eu-central-1, non eu-west-1 → eu-west-2)
Rete elettrica diversa (costa ovest vs costa est negli USA, diverse reti nazionali europee)
Zone tettoniche diverse dove rilevante

Per i workload soggetti a conformità, entrambe le region devono soddisfare la normativa. I dati GDPR devono restare nell'UE — replica da Parigi a Francoforte o Dublino, non a Virginia. Il Codice Privacy italiano richiede che le misure di sicurezza tecnica e organizzativa si applichino anche alla copia secondaria. Documenta la selezione delle region e la motivazione; i revisori del Garante della Privacy chiederanno.

Costo della replica cross-region

La replica ha tre componenti di costo:

Storage: doppio del costo primario (entrambe le region mantengono una copia)
Trasferimento dati: AWS addebita $0,02/GB per CRR tra region
Request fee: operazioni PUT alla destinazione

Per 10 TB replicati mensilmente, aspettati circa 700 €/mese su AWS tra Virginia e Oregon. Mitigazioni: replica verso una storage class più economica nella destinazione (S3 Glacier Instant Retrieval invece di Standard), filtra la replica per prefisso o tag per escludere i dati non critici, e usa le metriche di replica del bucket per intercettare la replica fuori controllo.

Il runbook di failover

Un runbook che esiste solo come idea è un runbook che fallisce. Un runbook pronto per la produzione copre:

Criteri di trigger: quali condizioni avviano il failover (pagina di stato della region, health check dell'applicazione, latenza P99 oltre soglia)
Autorità decisionale: chi prende la decisione (tipicamente VP Engineering + SRE lead, con soglie pre-approvate per il trigger automatico)
Passaggi: comandi esatti, in ordine, con output atteso
Verifica: come confermare che ogni passaggio abbia funzionato
Rollback: come tornare indietro se il failover stesso ha causato problemi
Comunicazione: aggiornamento status page, notifica clienti, Slack interno

Esempio di passaggio di failover per un'applicazione S3-backed: aggiorna Route 53 per puntare files.example.com dalla CloudFront del bucket primario a quella del bucket secondario. Testa con dig e un upload canary. Target di tempo: meno di 10 minuti.

Strategia DNS e routing

Il DNS di solito guida il failover. Opzioni:

Route 53 Failover routing: active-passive con switch automatico basato su health check
Route 53 Latency routing: traffico verso la region più vicina e sana
CloudFront con origin failover: trasparente per i client
Load balancer con backend multi-region: funziona ma aggiunge complessità

Il TTL conta. Un record DNS con TTL di 300 secondi fa failover in 5 minuti; uno con TTL di 3.600 secondi richiede un'ora. Imposta i record critici per il DR a TTL 60-300 secondi, accettando leggermente più traffico DNS per la convergenza più rapida.

Integrità dei dati durante il failover

Il ritardo di replica significa che il secondario è leggermente indietro. Fare failover può far perdere le scritture più recenti. Documenta l'RPO come perdita massima attesa e prepara un piano di riconciliazione:

Registra le scritture non confermate a livello applicativo così possono essere riprodotte
Cattura le transazioni in corso e ripriducile dai log degli eventi
Accetta la perdita esplicitamente (per i dati non critici, la semplicità è meglio)

Per gli upload di file nello specifico, un upload multipart interrotto dal failover può lasciare upload incompleti sul secondario. Configura le regole lifecycle AbortIncompleteMultipartUpload in entrambe le region per pulirli.

Testare il DR seriamente

Un piano DR testato e uno non testato sono animali diversi. Livelli di test:

Esercizio tabletop: percorri verbalmente il runbook. Trimestralmente.
Failover parziale: fai failover di un sottosistema (es. solo il file service). Semestralmente.
Failover regionale completo: fai failover di tutto in una finestra di manutenzione pianificata. Annualmente.
Chaos engineering: non pianificato, simulato, durante l'orario lavorativo. Trimestralmente per i sistemi Tier 0.

Registra tutto. Cosa si è rotto. Quanto tempo ha richiesto effettivamente ogni passaggio. Chi non riusciva a raggiungere la documentazione quando ne aveva bisogno. Migliora il runbook dopo ogni test. I team che fanno questo hanno failover che funzionano; quelli che non lo fanno scoprono i problemi durante gli incidenti reali.

I canali di comunicazione contano

Durante un incidente, la comunicazione nel cloud potrebbe essere non disponibile. Slack ospitato nella stessa region AWS che sta cedendo è inutile. Pre-arrangia canali fuori banda:

Un workspace Slack secondario ospitato in una region diversa
Bridge SMS via Twilio o Telnyx
Una rubrica telefonica personale come ultima risorsa
Una status page pubblica ospitata fuori dalla tua infrastruttura primaria (Atlassian Statuspage, StatusGator)

Documenta i canali nel raccoglitore fisico. Esercitati nel passaggio a essi.

Trasferire i file di recovery tra persone

Quando un guasto regionale blocca l'accesso agli strumenti di collaborazione normali, trasferire file specifici — un dump del database corrente, un export di configurazione, un playbook di risposta agli incidenti — necessita di un canale che funzioni indipendentemente dalla tua infrastruttura. Uno strumento amico dei dispositivi personali aiuta.

HexaTransfer funziona su qualsiasi browser senza configurazione account — utile quando il provider SSO è anch'esso offline, o quando i consulenti che intervengono devono ricevere file senza essere provisioning nel tuo tenant. La cifratura end-to-end AES-256-GCM garantisce che anche i momenti più stressanti a tastiera non facciano trapelare segreti in chiaro sulla rete.

Revisioni post-incident

Ogni test DR e ogni incidente reale merita un postmortem senza colpevoli. Documenta:

Timeline degli eventi
Cosa ha funzionato
Cosa non ha funzionato
Cause profonde (tecniche e di processo)
Action item con proprietari e scadenze

Traccia gli action item fino alla chiusura. Un postmortem con 20 azioni e zero completate è peggio di nessun postmortem — segnala al team che i miglioramenti non contano. Chiudi il cerchio e il prossimo incidente andrà meglio dell'ultimo.

Il disaster recovery è soprattutto disciplina. Definisci RPO/RTO, replica continuamente, documenta il runbook, testa trimestralmente e comunica fuori banda. La tecnologia è la parte facile.

Provalo su hexatransfer.com — gratuito, senza account, max 10 GB.