Azure Site Recovery: Disaster Recovery di Azure VM tra Region diverse

Mai come negli ultimi anni le aziende si sono rese conto che garantire la continuità operativa e la protezione dei dati è fondamentale per evitare gravi interruzioni e le relative perdite economiche.
Azure Site Recovery (ASR) è la soluzione di Disaster Recovery (DR) di Microsoft progettata per aiutare le aziende a proteggere i propri carichi di lavoro, riducendo i tempi di inattività e assicurando il ripristino rapido in caso di guasti o incidenti.
Con questo strumento sarà possibile replicare macchine virtuali, server fisici e applicazioni critiche in un secondo sito oppure direttamente in Azure.

Nicola Ferrini in passato ha già parlato di ASR nei seguenti articoli:

Questa guida vuole, quindi, essere una sorta di aggiornamento visti i cambiamenti procedurali alla soluzione. Restano, comunque, validi i concetti espressi in precedenza.
Come indicato nel titolo, vedremo il processo di protezione di una Virtual Machine in Azure utilizzando una seconda regione.

Architettura della soluzione

Prima di iniziare è importante descrivere l’architettura, i componenti e i processi coinvolti nell’implementazione del DR per le Azure VM utilizzando ASR.
Le Virtual Machine vengono replicate continuamente in una regione secondaria. In caso di interruzione, è possibile eseguire il Failover delle VM nella regione di destinazione e accedervi da lì.
Una volta ripristinata la normalità, è possibile eseguire il Failback e riprendere le operazioni nella regione primaria.

Figura 1: Componenti di Azure Site Recovery

Possiamo riassumere i componenti della soluzione in questo modo:

  • Macchine Virtuali nella regione sorgente
  • Storage delle macchine virtuali sorgente
  • Network delle VM sorgente
  • Cache Storage Account
  • Risorse di destinazione

In particolare le risorse target includono Subscription, Resource Group, VNet, Storage.

Per quanto riguarda i costi è necessario chiarire alcuni aspetti.
Innanzitutto è consigliabile utilizzare il calcolatore Azure per avere una stima completa e aggiornata, ma possiamo riassumere (con le tariffe presenti oggi) le fee standard:

  • Ripristino in siti di proprietà dei clienti: € 15,35 per istanza protetta
  • Ripristino in Azure: € 23,99 per istanza protetta

Oltre ai suddetti costi fissi dovremo considerare anche:

  • Replica Storage: rispecchia lo storage della sorgente. Viene utilizzato durante la replica, il tipo e la dimensione dipendono dalla configurazione dello storage sorgente.
  • Cache Storage Account: si trova nella regione di origine. Utilizzando l’opzione High Churn (alto tasso di modifica) viene utilizzato viene utilizzato Premium Block Blob. Per il Normal Churn (normale tasso di modifica), viene usato un General Purpose Storage Account.
  • Storage Transactional: generano costi durante la replica e dopo un failover/test. Questi derivano dalle operazioni di lettura/scrittura sull’account di cache. I costi aumentano con più dischi e dipendono dal tasso di modifica per la replica delta.
  • Network Egress: si applicano alla replica tra regioni Azure. ASR riduce i costi comprimendo i dati fino al 50%.
  • Snapshot: include istantanee incrementali per dischi Pv1, una istantanea completa seguita da incrementali per Pv2 e le istantanee dei punti di ripristino nel target, addebitate in base allo spazio utilizzato secondo i prezzi dei Page Blob Snapshots.
  • Temporary Source Disk: si applica solo alla replica iniziale (circa 6 ore per 1 TB) con addebito sul disco temporaneo, che mantiene dimensione e SKU dell’originale.

Infine, per chi desiderasse provare la soluzione, i primi 31 giorni di protezione di una istanza sono gratuiti anche se, chiaramente, restano intesi i costi menzionati prima per storage e trasferimento dati.

Protezione di una Azure VM

Fatte le dovute premesse possiamo iniziare con il processo di protezione delle istanze virtuali tramite Azure Site Recovery. In questo esempio vedremo gli step utili a creare un sito di DR nella Region francese (France Central), partendo da quella italiana (Italy North).
Importante chiarire che le risorse di destinazione non potranno essere nello stesso Resource Group. Ne verrà, infatti, creato automaticamente uno nuovo e, al contempo, saranno generate anche le risorse network necessarie.

Figura 2: Selezione VM da proteggere

Figura 3: Accesso all’area di configurazione di ASR

Figura 4: Selezione Region di destinazione

Nel prossimo passaggio selezioneremo le opzioni relative alle risorse destinazione della replica. Tra queste è utile segnalare i Proximity Placement Group e i Capacity Reservation Settings.
I primi aiutano a ridurre la latenza tra le VM collocandole fisicamente il più vicino possibile all’interno dello stesso Data Center, mentre i secondi garantiscono che nella regione target vi sia disponibile la capacità necessaria.
Selezionando una delle due opzioni vedremo che l’altra risulterà non disponibile poiché le due funzionalità hanno requisiti di allocazione delle risorse potenzialmente incompatibili.

Figura 5: Impostazioni destinazione

Proseguendo dovremo scegliere il Churn, di cui abbiamo parlato in precedenza, per la macchina virtuale e la tipologia di disco.
Verranno creati i Vault necessari e impostata la Replication Policy, un insieme di regole che definisce come vengono replicati i sistemi dal sito primario a quello di destinazione.

Figura 6: Impostazioni Storage

Gli Extension Settings si riferiscono alla gestione delle estensioni di Azure installate sulle macchine virtuali replicate. Queste impostazioni permettono di controllare come le estensioni vengono gestite dopo il Failover o durante il processo di Replica.
In particolare è possibile selezionare se aggiornarle automaticamente tramite ASR oppure se eseguire gli aggiornamenti delle estensioni manualmente.

Figura 7: Impostazione update settings estensioni

Figura 8: Review e avvio del processo di Replica

Figura 9: Nuovi Resource Group creati da ASR

Tramite il pannello di gestione del Recovery Vault possiamo avere informazioni in merito allo stato di salute della replica, del failover e di quale sia la location attiva.
In questo esempio vedremo un caso di protezione non andata a buon fine e come eseguire un primo troubleshooting.

Figura 10: Site Recovery Vault

Figura 11: Processo di replica in errore

Figura 12: Errore in fase di preparazione del target

Figura 13: Dettaglio errore nella fase di protezione della VM

Dall’immagine è chiaro che la versione del sistema operativo della macchina virtuale di origine non è supportato (Ubuntu 24.04) e ci viene consigliato di consultare la matrice di compatibilità nella documentazione Microsoft.
È, quindi, chiaro che prima di procedure con l’attivazione della protezione delle VM è importante verificarne la compatibilità.

Vediamo ora un processo andato a buon fine utilizzando una virtual machine con sistema operativo Windows Server 2025.
Come in precedenza selezioniamo il sistema da replicare e procediamo con le medesime operazioni.

Figura 14: Selezione della macchina Windows Server

Figura 15: Stato replica Healty

A questo punto potremo verificare lo stato della replica direttamente dalla sezione Disaster Recovery della VM. Mentre nel Resource Group di destinazione sarà ora presente un nuovo disco, che verrà sincronizzato con i dati della macchina di origine e utilizzato in caso di Failover.

Figura 16: In attesa del primo Recovery Point

Figura 17: Disco replicato dal sorgente

Non appena la virtual machine sarà in stato Protected sarà possibile eseguire il Failover Test, una funzionalità che permette di simulare un failover senza impattare l’ambiente di produzione.
È estremamente importante poiché serve per verificare che il piano di Disaster Recovery funzioni correttamente e che le VM possano essere avviate con successo nella regione di destinazione.
Tornando, quindi, nella sezione vista in precedenza potremo procedere.

Figura 18: Avvio processo di test del Failover

Prima di confermare l’avvio del test di Failover dovremo selezionare la VNet di destinazione e il Recovery Point.
Latest Processed (Lowest RTO) è il recovery point più recente replicato nella destinazione, garantendo un ripristino rapido ma senza coerenza applicativa, mentre Latest App-Consistent è un recovery point che include snapshot coerenti con le applicazioni (es. database e file system), assicurando integrità dei dati ma con un tempo di ripristino maggiore.

Figura 19: Test di Failover

Dopo aver eseguito tutti i test utili alla verifica della procedura di Failover potremo effettuare un Cleanup test failover ed eliminare la macchina virtuale creata in automatico.

Figura 20: Cleanup test failover

Figura 21: Completamento Cleanup e cancellazione VM

Processo di Failover

L’attivazione del Failover a questo punto è piuttosto semplice e simile alla procedura vista in precedenza. In questa fase sceglieremo il Recovery Point e potremo spegnere la macchina virtuale di origine. Chiaramente in una situazione di disastro diamo per scontato che la VM sia già non utilizzabile, ma il consiglio è di spuntare sempre quella opzione.

Figura 22: Avvio processo di Failover

Figura 23: Selezione Recovery Point

Figura 24: Shutdown della VM e conferma processo di Failover

Quando il Failover sarà completato potremo cambiare il Recovery Point (Change recovery point) oppure confermare quello scelto in precedenza tramire il comando di Commit.
Bisogna sottilineare che una volta eseguito il Commit non sarà più possibile cambiare il punto di ripristino.

Figura 25: Commit e completamento del processo di Failover

Dopo un Failover in Azure Site Recovery (ASR), quando il disastro sarà rientrato, per eseguire il Failback in sicurezza dovremo prima utilizzare il comando Re-protect, ovvero il processo che inverte la direzione della replica per ristabilire la protezione dell’ambiente originale.
Per impostazione predefinita Site Recovery selezionerà il gruppo di risorse, la rete virtuale, gli account di archiviazione e i set di disponibilità di origine, ma è possibile cambiare questi parametri.

Figura 26: Re-protect dell’istanza virtuale

Figura 27: Completamento del processo di Re-protect

Dopo aver eseguito il Re-protect il sito primario è pronto per ricevere di nuovo la VM replicata.
Per completare il Failback dovremo, quindi, tornare nel Recovery service vault, alla sezione Replicated items e, selezionando la virtual machine da ripristinare, eseguire un nuovo Failover versi il Primary Site.

Figura 28: Selezione VM da ripristinare

Figura 29: Esecusione Failover (Failback)

Figura 30: Failback verso la Region originale

Figura 31: Operazioni di ripristino della VM completate

Conclusioni

Il Disaster Recovery è fondamentale nell’era digitale, data la nostra crescente dipendenza dai sistemi IT.
Nonostante tutte le precauzioni, eventi imprevisti possono comunque compromettere l’accesso ai servizi. Sebbene il Cloud offra un’elevata affidabilità, è sempre prudente prepararsi a eventuali emergenze.
La replica delle macchine virtuali in Azure rappresenta una soluzione efficace per garantire la continuità operativa in caso di gravi interruzioni. Inoltre questa funzionalità è particolarmente utile per le aziende con requisiti stringenti o obblighi contrattuali in materia di Disaster Recovery, assicurando loro la conformità alle specifiche richieste e la possibilità di ripristinare rapidamente le VM ospitate in Azure.