• Cloud, Guide, Sicurezza
• 19 Marzo 2025

Azure Site Recovery (ASR) è una soluzione di Disaster Recovery (DR) che consente di orchestrare la replica e il Failover di virtual machine in caso di emergenza.
Nella guida “Disaster Recovery di Azure VM tra Region diverse” abbiamo iniziato a conoscere gli strumenti basilari che caratterizzano il prodotto, oggi vedremo una delle funzionalità chiave di ASR: i Recovery Plans che permettono di definire il flusso di Failover e automatizzare le operazioni necessarie al ripristino dell’infrastruttura.

Nello specifico i Recovery Plans in Azure Site Recovery consentono di:

• Definire la sequenza di Failover delle macchine virtuali
• Aggiungere gruppi di VM per un avvio ordinato
• Integrare script personalizzati e Azure Runbooks per automatizzare azioni specifiche

Per meglio capire il funzionamento dei Recovery Plans e delle motivazioni per cui è bene utilizzarli faremo un esempio pratico. Nella infrastruttura di laboratorio avremo:

• Domain Controller
• File Server
• Database Server
• Web Server

Immaginiamo che dal Domain Controller dipendano, per la parte di autenticazione, File Server e Database Server e che il Web Server a sua volta dipenda dal Database Server per quanto concerne i dati. Viene da sé che è opportuno dare una giusta sequenza di avvio per rispettare le relazioni tra le macchine.

Figura 1: Infrastruttura di laboratorio

Le configurazioni relative ad Azure Site Recovery sono raggiungibili tramite il Recovery Services Vault associato, in questo caso all’interno del Resource Group “rg-site-recovery”.
Successivamente, nell’area di gestione (Manage) potremo creare il nostro Recovery Plan.

Figura 2: Accesso al Recovery Services Vault

Figura 3: Creazione del Recovery Plan

In questa fase, oltre a inserire nome del RP, dovremo selezionare la Region sorgente (in questo caso West Europe) e la destinazione (Germany West Central). Andranno indicate anche le istanze da gestire con il piano di ripristino.

Figura 4: Processo di creazione del Recovery Plan

Figura 5: Selezione VM di cui orchestrare il ripristino

Figura 6: Creazione del piano dopo aver selezionato le istanze necessarie

Figura 7: Piano di ripristino creato

Terminato il processo di creazione del piano dovremo personalizzarlo indicando la corretta sequenza di ripristino.
Inizialmente tutte la VM saranno all’interno di un unico gruppo (Group 1) quello che dovremo fare sarà creare altri due gruppi così da suddividerle in base alle nostre esigenze di recovery.
Prepareremo, quindi, i gruppi 2 e 3 inserendo rispettivamente File Server e Database Server nel secondo, mentre Web Server nel terzo. Lasceremo, chiaramente, il Domain Controller nel primario.

Figura 8: Personalizzazione del piano

Figura 9: Stato iniziale del Recovery Plan

Figura 10: Creazione nuovi gruppi

Figura 11: A fronte della creazione dei nuovi gruppi, salvataggio del piano

Figura 12: Inserimento delle VM nei gruppi preposti

Figura 13: Salvataggio del piano modificato

Figura 14: Situazione a fronte delle modifiche

Arrivati a questo punto le procedure di Failover e Failback sono le medesime già viste nella precedente guida. Potremo anche eseguire un Test Failover.
Una volta verificati i parametri, avvieremo il processo di Failover che seguirà l’ordine di avvio indicato nel Recovery Plan.

Figura 15: Avvio del processo di Failover

Figura 16: Conferma delle impostazioni

Figura 17:Le VM vengono avviate seguendo l’ordine indicato

Figura 18: Completamento del processo di Failover

Proseguendo faremo il Commit che, ricordiamo, conclude il processo di Failover e non permette di cambiare il punto di ripristino delle VM.
Successivamente eseguiremo il Failback per tornare alla situazione iniziale, con il Re-protect delle macchine invertiremo la direzione di replica per ristabilire la protezione dell’ambiente originale.

Figura 19: Esecuzione del Commit

Figura 20: Inversione della direzione di replica

Figura 21: Conferma del Re-Protect

Di fatto il Failback non è altro che un nuovo Failover dal sito di destinazione verso il primario, la sorgente originale. Eseguiremo, dunque, le stesse operazioni viste in precedenza.
Anche in questo caso verrà rispettato l’ordine indicato nel Recovery Plan.

Figura 22: Failback dalla region secondaria verso la primaria

Figura 23: Conferma dei paramentri di Failover

Figura 24: Completamento del Failback

Utilizzo di Runbook nei Recovery Plan

I Runbook sono script di automazione eseguiti all’interno di Azure Automation. Possono essere utilizzati per automatizzare operazioni ripetitive o personalizzare il comportamento dei processi Azure Site Recovery.
In questo esempio vedremo come inviare una e-mail a fronte di una situazione di disastro e al conseguente Failover. Ovviamente è solo una delle possibilità, perché, in quanto azioni personalizzate, è possibile eseguire qualsiasi tipo di attività (invio di messaggi Teams, creazione di una VM di servizio, ecc.)

Per questo specifico caso sarà necessario creare una Applicazione in grado di inviare una mail per conto di un utente dell’organizzazione. Questo account dovrà avere una licenza abilitata all’invio di posta (Exchange Online).

Figura 25: Sezione App Registrations

Figura 26: Registrazione di una nuova applicazione

Figura 27: Inserimento parametri nuova Applicazione

Lo script che andremo a creare avrà necessità dei seguenti valori:

• Application (client) ID
• Directory (tenant) ID
• Client Secret
• Indirizzo del Sender
• Indirizzo del destinatario

Figura 28: Schermata iniziale applicazione

Figura 29: Creazione del Client secret

Figura 30: Copia del Value del secret

L’applicazione dovrà avere le permission necessarie all’invio di e-mail tramite Microsoft Graph:

• Mail.Send
  
• User.Read.All
  

Figura 31: Aggiunta API permissions

Figura 32: Selezione di Microsoft Graph

Figura 33: Selezione di Application Permissions

Figura 34: Aggiunta delle permissions necessarie

Figura 35: Concessione dei privilegi amministrativi

Attraverso un Automation Account, che dovrà essere in una Region differente da quella utilizzata dalle risorse coinvolte nel processo di DR, potremo creare il Runbook utile all’invio delle comunicazioni.
Prima dell’utilizzo il Runbook andrà pubblicato (Publish).

Figura 36: Creazione di un nuovo Runbook

Figura 37: Selezione impostazioni Runbook e creazione

Figura 38: Creazione script invio e-mail

Il codice che ho utilizzato per questo esempio è il seguente, può, chiaramente, essere personalizzato a proprio piacimento:

È possibile fare un test di funzionamento dello script prima di mandarlo in produzione.

Figura 39: Test funzionamento dello Script

Quando tutto sarà pronto potremo (finalmente!) inserire nel nostro piano di ripristino il Runbook.
Volendo far inviare una comunicazione all’inizio del Failover aggiungeremo lo script come pre-action nel gruppo 1, ovvero il primo di cui verrà eseguito il recovery.

Figura 40: Inserimento script come pre-action

Figura 41: Selezione Runbook

Figura 42: Esempio di e-mail ricevuta

Conclusioni

L’integrazione di Azure Site Recovery con i Recovery Plan e l’uso dei Runbook offre un potente strumento per automatizzare e ottimizzare il processo di Disaster Recovery.
Grazie ai Recovery Plan è possibile orchestrare il Failover in modo strutturato, garantendo la ripresa operativa dei servizi in maniera ordinata e controllata.
L’aggiunta dei Runbook consente di automatizzare operazioni critiche, come notifiche, aggiornamenti di configurazione e scalabilità delle risorse, riducendo i tempi di inattività e minimizzando gli errori manuali.