Due servizi, due obiettivi diversi

La confusione più frequente in esame nasce dal trattare Azure Backup e Azure Site Recovery (ASR) come alternative. Non lo sono: rispondono a esigenze diverse e nella pratica convivono nella stessa strategia di resilienza.

  • Azure Backup protegge e ripristina i dati (VM, file, cartelle, database) da corruzione, cancellazione accidentale o ransomware. È una macchina del tempo: recuperi uno stato precedente.
  • Azure Site Recovery replica interi workload verso una regione secondaria e ne esegue il failover in caso di disastro regionale. È continuità operativa: sposti l’esecuzione, non recuperi un file.

In sintesi: Backup risponde a “ho perso/corrotto dei dati”, ASR risponde a “la mia regione primaria è down e devo continuare a lavorare altrove”.

Azure Backup e il Recovery Services vault

Il Recovery Services vault è il contenitore logico che ospita i recovery point e le policy. Un vault può proteggere più tipi di carico:

  • Azure VM backup: snapshot a livello di VM tramite l’estensione di backup, con opzione application-consistent (VSS su Windows, pre/post-script su Linux) contro il semplice crash-consistent.
  • File e cartelle tramite MARS agent (Microsoft Azure Recovery Services), utile per backup granulare da server on-premises o dentro la guest OS.
  • SQL Server / SAP HANA in Azure VM, con backup log frequenti e point-in-time restore.
  • Azure Files, gestito nativamente a livello di share.

La backup policy definisce frequenza (schedule) e retention (giornaliera, settimanale, mensile, annuale, in stile GFS – Grandfather-Father-Son). All’esame ricorda che aumentare la retention aumenta i costi di storage e che la retention si applica per singolo recovery point secondo la regola con cui è stato creato.

Azure Site Recovery: replica e failover

ASR replica in continuo i dischi della VM verso la regione di DR. I concetti chiave:

  • Replication policy con recovery point retention e frequenza degli app-consistent snapshot.
  • Test failover: valida il piano di DR in una rete isolata senza impatto sulla produzione. È la scelta corretta ogni volta che lo scenario chiede di “verificare il DR senza interrompere il servizio”.
  • Failover e failback (reprotect + failover inverso) per tornare in primaria.
  • Recovery Plan: orchestrazione dell’ordine di failover di più VM con script e gruppi, essenziale per applicazioni multi-tier.

RPO e RTO

  • RPO (Recovery Point Objective): quanti dati ti puoi permettere di perdere, cioè la distanza temporale tra l’ultimo recovery point e il disastro. Lo abbassi aumentando la frequenza di backup/replica.
  • RTO (Recovery Time Objective): quanto tempo puoi restare down. ASR con recovery plan orchestrati ottiene RTO molto più bassi di un restore completo da Backup.

Requisito di RPO bassissimo (minuti) e failover regionale → ASR. Requisito di recupero granulare di file con retention lunga → Backup.

Vault redundancy: la scelta irreversibile

La ridondanza dello storage del Recovery Services vault determina dove vivono le copie:

  • LRS (Locally Redundant Storage): 3 copie in un solo datacenter. Più economico, ma non protegge da disastro regionale.
  • ZRS (Zone Redundant Storage): copie su availability zone diverse nella stessa regione.
  • GRS (Geo Redundant Storage): replica in una regione secondaria accoppiata. Prerequisito per il Cross Region Restore (CRR), che permette di ripristinare i backup nella regione secondaria.

Punto critico d’esame: la redundancy va scelta prima del primo backup. Una volta che il vault contiene recovery point, l’opzione non è più modificabile. Se prevedi resilienza geografica, imposta GRS (+ CRR) in fase di creazione.

Trappole tipiche d’esame

  • Scenario: recuperare un singolo file cancellato da una VM → Azure Backup (item-level restore), NON ASR: ASR fa failover di workload, non ripristina file.
  • Scenario: la regione primaria è inagibile e serve tornare operativi in un’altra regione con RTO basso → Azure Site Recovery con recovery plan orchestrato.
  • Scenario: il vault è già impostato su LRS ma serve resilienza geografica dopo i primi backup → non puoi cambiare la redundancy; scegli GRS prima del primo backup (o crea un nuovo vault).
  • Scenario: validare il piano di DR senza toccare la produzione → Test failover in rete isolata, mai un failover reale.
  • Scenario: ridurre la perdita di dati (RPO) vs ridurre il downtime (RTO) → aumenta la frequenza per l’RPO; usa orchestrazione/replica per l’RTO. Non confondere i due obiettivi.