Microsoft AZ-801: Disaster Recovery e Continuità Operativa — Guida allo studio

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

Fa parte della Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Panoramica

La progettazione del disaster recovery (DR) e della continuità operativa (BC) inizia con la quantificazione di due metriche: l’Obiettivo di tempo di ripristino (RTO) e l’Obiettivo del punto di ripristino (RPO). L’RTO rappresenta la rapidità con cui è necessario ripristinare il servizio; l’RPO definisce la quantità di perdita di dati (in termini di tempo) accettabile. Questi valori guidano le scelte tecnologiche, la topologia e i costi. Un RTO basso favorisce l’orchestrazione e l’automazione (piani di ripristino di Azure Site Recovery, runbook e risorse di destinazione pre-create). Un RPO basso favorisce la replica continua (ASR) o il commit sincrono (SQL Always On), mentre un RPO più alto può basarsi su backup periodici (Azure Backup, Windows Server Backup). I gruppi di coerenza multi-VM e gli snapshot coerenti con l’applicazione preservano l’integrità transazionale tra le VM quando è richiesto un RPO rigoroso. La scelta del vault (Recovery Services vault o Backup vault), la progettazione dei criteri di replica e la pianificazione dei backup vengono selezionati per soddisfare questi obiettivi senza eccedere nella spesa.

Azure Site Recovery: Hyper-V, VMware, orchestrazione e coerenza

Azure Site Recovery (ASR) fornisce replica continua e failover/failback orchestrati per VM on-premise VMware, Hyper-V e IaaS di Azure.

Protezione di Hyper-V

Criterio di replica: Definisce la soglia RPO, la conservazione dei punti di ripristino e la cadenza degli snapshot coerenti con l’applicazione. Ad esempio, impostare la soglia RPO a 15 minuti, conservare i punti di ripristino per 24-72 ore per il rollback point-in-time e acquisire snapshot coerenti con l’applicazione ogni 1-4 ore. I criteri controllano la limitazione della larghezza di banda e la compressione; la coerenza multi-VM può essere abilitata per le VM correlate in modo che i loro punti di ripristino siano allineati.
Punti di ripristino: ASR mantiene continuamente punti coerenti con l’arresto anomalo e punti aggiuntivi coerenti con l’applicazione quando il quiescing VSS ha successo. La conservazione consente di selezionare punti precedenti per mitigare la corruzione logica o i ransomware.
Failover di test: Esercitazioni non distruttive che convalidano i runbook, l’ordine di avvio e la rete. Utilizzare una VNet isolata, fornire valori di input per il test (ad es. IP dei DNS) e assicurarsi che la risoluzione dei nomi sia isolata. La replica di produzione continua senza interruzioni e la pulizia rimuove gli artefatti del test dopo la convalida. Stabilire in anticipo la mappatura di rete e testare le mappature delle NIC per evitare conflitti di IP.

Protezione di VMware

Configuration server: L’appliance on-premise che si registra con il Recovery Services vault, rileva l’inventario di vCenter/ESXi, coordina la replica e distribuisce gli agenti del Mobility Service. È il piano di controllo per la protezione di VMware.
Process server: Solitamente collocato inizialmente insieme al configuration server; esegue il rilevamento delle modifiche, la compressione, la crittografia e il trasferimento dei dati verso Azure. Vengono aggiunti process server in scale-out per aumentare il throughput e per posizionare il traffico in ingresso vicino agli host protetti per minimizzare la latenza.
Master target server: Utilizzato per il failback da Azure a VMware. Riceve le modifiche replicate durante la riprotezione e fornisce una landing zone per poter ripristinare i carichi di lavoro su vSphere. Dimensionare lo storage per la velocità di scrittura aggregata durante il failback e assicurarsi che il throughput di rete corrisponda alle finestre di risincronizzazione di picco.
Mobility Service: Installato in ogni VM protetta per catturare le modifiche del disco. Mantenere aggiornate le credenziali o i meccanismi di push e monitorare lo stato di salute dell’agente nel vault.

Orchestrazione e coerenza

Piani di ripristino: Runbook dichiarativi per il DR che definiscono raggruppamenti, ordine di avvio, passaggi di approvazione manuale e attività di automazione. Utilizzare i runbook di Azure Automation per riconfigurare gli NSG, aggiornare i record DNS, pre-riscaldare le cache delle applicazioni o eseguire script SQL. Assegnare gruppi logici come i livelli “Dati”, “App” e “Web” e inserire pause per la convalida.
Runbook: Automatizzano attività specifiche dell’ambiente come l’inversione degli endpoint di Traffic Manager, il dimensionamento delle dipendenze PaaS o la disabilitazione del monitoraggio on-premise durante il failover per ridurre i falsi allarmi. Parametrizzarli per il failover di test rispetto a quello di produzione.
Gruppi di coerenza multi-VM: Abilitarli per i livelli che condividono lo stesso ordine di scrittura (ad es. server applicativo e writer dei log del database). Ciò garantisce un punto nel tempo coerente tra le VM; sacrifica il throughput in favore della correttezza e dovrebbe essere limitato alle VM veramente interdipendenti.

Impatto su RTO/RPO

RPO rigoroso: Preferire ASR con replica aggressiva e snapshot coerenti con l’applicazione, process server dimensionati per il throughput e reti di replica dedicate. Per i database, considerare il commit sincrono di Always On all’interno di un’area metropolitana.
RTO rigoroso: Pre-creare VNet, subnet e load balancer di destinazione; utilizzare piani di ripristino con automazione per eliminare i passaggi manuali. Utilizzare regolarmente i failover di test per stabilire una baseline dell’RTO previsto.

Backup e ripristino: Azure Backup (MARS, MABS/DPM), insiemi di credenziali e Windows Server Backup

Azure Backup fornisce una protezione point-in-time per i carichi di lavoro on-premise e in Azure. Scegliere l’agente e il tipo di insieme di credenziali corretti in base al carico di lavoro e alle funzionalità.

Agente MARS (Microsoft Azure Recovery Services agent)

Criterio di backup: Configurare fino a tre backup giornalieri con conservazione granulare (giornaliera/settimanale/mensile/annuale) nell’insieme di credenziali di Servizi di ripristino. Selezionare la ridondanza dell’archiviazione (LRS o GRS) e allineare la conservazione ai requisiti di conformità, controllando al contempo la crescita dell’insieme di credenziali. Pianificare al di fuori dei picchi di I/O e abilitare la limitazione della larghezza di banda di rete dove necessario.
Backup dello stato del sistema: Supportato con MARS per Windows Server per proteggere AD, registro, COM+ e file di avvio. Utilizzare per il ripristino del controller di dominio (autorevole/non autorevole) o per la riparazione del sistema operativo senza un backup completo a livello di immagine.
Ripristino online: Ripristinare file/cartelle usando Sfoglia o Cerca. Il Ripristino immediato (Instant Restore) monta il punto di ripristino come volume per una copia rapida dei file. È possibile ripristinare nei percorsi originali o alternativi e anche su un altro server, utilizzando le credenziali dell’insieme di credenziali sulla destinazione e autenticandosi all’insieme di credenziali.
Gestione della passphrase: L’agente MARS utilizza una passphrase di crittografia (AES-256) gestita dal cliente, generata e archiviata localmente; Microsoft non ne entra mai in possesso. La perdita della passphrase rende impossibile il ripristino. Archiviarla in una posizione sicura e sottoposta a backup (ad es. un segreto di Key Vault protetto da HSM con RBAC). Per ruotarla, interrompere la protezione e riproteggere con una nuova passphrase. Abilitare le funzionalità di eliminazione temporanea (soft delete) e PIN di sicurezza nell’insieme di credenziali per proteggersi da interruzioni/eliminazioni dannose.

Azure Backup con MABS/DPM e IaaS

Backup per il ripristino bare metal (BMR): Utilizzare Microsoft Azure Backup Server (MABS) o System Center DPM per acquisire un BMR per Windows Server. Ciò consente ricostruzioni complete del server su nuovo hardware o su una VM, avviando WinRE o il supporto di installazione e puntando all’immagine BMR.
Ripristino in una posizione alternativa: Per i backup di file/dati tramite MARS/MABS/DPM, ripristinare in un percorso alternativo o su un server diverso per evitare di sovrascrivere i dati di origine. Per i backup di VM IaaS di Azure (in un insieme di credenziali di Servizi di ripristino), ripristinare su una nuova VM, ripristinare i dischi su una VM esistente o sostituire i dischi. Con il Ripristino tra aree (Cross-Region Restore) abilitato sull’insieme di credenziali, è possibile eseguire il ripristino nell’area abbinata per scenari di interruzione a livello di area.
SQL e SAP HANA in VM di Azure: Proteggere con estensioni specifiche per il carico di lavoro (workload-aware) per ottenere backup coerenti con l’applicazione e ripristino granulare del database. Allineare la frequenza del backup dei log all’RPO (ad es. 15 minuti) e la conservazione ai requisiti di conformità.

Windows Server Backup (WSB)

Ripristino bare metal: WSB può acquisire un BMR (volumi di sistema e stato del sistema). Archiviare su un disco o volume dedicato per avere più punti di ripristino. Per le destinazioni su condivisione di rete, viene mantenuta solo la versione più recente. Ripristinare avviando dal supporto di Windows in WinRE e selezionando “Ripristino immagine del sistema”.
Backup dello stato del sistema: Fornisce un ripristino rapido di AD DS, registro e file di avvio. Utile per controller di dominio e server di configurazione. Combinare con backup di file pianificati per una copertura più ampia.
Pianificazione: Utilizzare la console MMC di WSB o wbadmin per pianificare backup giornalieri/orari. Scegliere VSS Full o Copy a seconda che si desideri troncare i log dell’applicazione. Assicurarsi che le finestre di backup evitino i picchi di I/O e verificare l’integrità del catalogo (wbadmin get versions).

Tipi di insiemi di credenziali: Insieme di credenziali di Servizi di ripristino vs Insieme di credenziali di Backup

Insieme di credenziali di Servizi di ripristino (RSV): L’insieme di credenziali tradizionale per i backup di VM di Azure, i backup con l’agente MARS, MABS/DPM, il backup di Azure Files, SQL Server in VM di Azure e SAP HANA in VM di Azure. Ospita anche i metadati di ASR. Supporta funzionalità come l’eliminazione temporanea (soft delete), il PIN di sicurezza e il Ripristino tra aree (Cross-Region Restore) (ove applicabile).
Insieme di credenziali di Backup: L’insieme di credenziali modernizzato per determinati carichi di lavoro nativi di Azure come il backup di Azure Disks e il backup di Azure Blobs, e i server flessibili di Database di Azure per PostgreSQL. Utilizza Azure RBAC per l’autorizzazione a livello di piano di gestione, supporta chiavi gestite dal cliente, opzioni di immutabilità e si integra con Resource Guard per la protezione delle operazioni critiche. Non ospita i metadati di ASR e, ad oggi, non sostituisce l’RSV per MARS/MABS/DPM o per la maggior parte dei backup di VM IaaS.

HA a livello di applicazione: SQL Always On e DFS Replication

Alcuni carichi di lavoro richiedono una replica nativa che integri o sostituisca il DR a livello di hypervisor a seconda di RTO/RPO.

Always On Availability Groups (AGs)

Commit sincrono e asincrono: Il commit sincrono attende che il secondario scriva il log su disco (harden the log) prima di eseguire il commit della transazione sul primario, garantendo una perdita di dati quasi nulla (RPO basso) a scapito di latenza e throughput; da utilizzare su collegamenti a bassa latenza (tipicamente in area metropolitana). Il commit asincrono non attende il secondario, consentendo prestazioni più elevate su collegamenti WAN con una potenziale perdita di dati durante il failover (RPO più alto).
Condizioni di failover automatico: Il failover automatico richiede almeno due repliche a commit sincrono con il failover automatico abilitato e sincronizzate. Il Windows Server Failover Clustering monitora lo stato di salute (health) di nodi e servizi; la policy di failover flessibile di SQL Server definisce i livelli delle condizioni di guasto (da crash di processi a gravi problemi di I/O). È possibile abilitare il rilevamento dello stato di salute del database (database health detection) per forzare un failover quando il database primario è sospetto. La progettazione di quorum e witness assicura che venga evitato lo split-brain; assicurarsi che i DNS e gli IP del listener siano pronti nel sito di ripristino per una rapida riconnessione dei client.

DFS Replication (DFSR)

Gruppi di replica e connessioni: Un gruppo di replica è un insieme di server che replicano una o più cartelle replicate. Le connessioni definiscono la topologia (full mesh, hub-spoke) e la pianificazione/limitazione della larghezza di banda (bandwidth throttling). Utilizzare la topologia hub-spoke per favorire la scalabilità e semplificare il troubleshooting.
Area di staging: DFSR utilizza un’area di staging per ogni cartella replicata per conservare i file delta per la Remote Differential Compression (RDC). Dimensionare l’area di staging ad almeno la dimensione del file più grande e tipicamente 1-2 volte il churn giornaliero previsto; un dimensionamento insufficiente causa pulizie e tentativi eccessivi, danneggiando RPO/RTO.
Risoluzione dei conflitti: DFSR è multi-master. Quando si verificano modifiche simultanee, DFSR utilizza vettori di versione e timestamp; l’ultima scrittura prevale (last-writer wins) e la copia perdente viene spostata nella cartella ConflictAndDeleted (il cui spazio è gestito da una quota). Per evitare conflitti iniziali durante il seeding, impostare un membro primario solo per la sincronizzazione iniziale. Per scenari unidirezionali, utilizzare cartelle replicate di sola lettura (read-only). Monitorare i backlog con dfsrdiag e ottimizzare le pianificazioni per rispettare l’RPO.

Impatto sull’architettura di RTO/RPO e dei piani di DR integrati

RPO aggressivo: Privilegiare la replica sincrona dei database o ASR con elaborazione delle modifiche ad alta frequenza e snapshot coerenti con l’applicazione. Isolare il traffico di replica e scalare i process server. Utilizzare i gruppi di coerenza multi-VM con parsimonia solo per i tier strettamente accoppiati.
RTO aggressivo: Pre-provisionare VNet, subnet, tabelle di routing (Route Tables) e NSG di destinazione; creare script per la riassegnazione degli IP e gli aggiornamenti DNS tramite piani di ripristino e runbook. Mantenere le golden image e le dimensioni delle VM ancorate a SKU con capacità disponibile. Testare i failover trimestralmente e dopo modifiche sostanziali.
Stratificazione della protezione dei dati: Combinare ASR (ripristino rapido del servizio) con Azure Backup (rollback a un punto nel tempo) per gestire sia i guasti catastrofici sia la corruzione logica. Per i controller di dominio, abbinare i backup dello stato del sistema (System State) (MARS o WSB) con ASR/failover di test per convalidare un ripristino sicuro dal rollback degli USN. Per i servizi file, DFSR fornisce alta disponibilità all’interno e tra i siti, con Azure Backup per un ripristino resistente ai ransomware.

Scenario pratico

Fabrikam, Inc., un produttore globale, gestisce un ambiente misto: Hyper-V per i tier applicativi dell’ERP, VMware per il middleware legacy, Gruppi di Disponibilità (AG) di SQL Server 2019 per i database e grandi file server Windows che utilizzano DFS Replication. Il business richiede un RTO ≤ 1 ora e un RPO ≤ 15 minuti per l’ERP; gli altri carichi di lavoro possono tollerare un RTO di 4 ore e un RPO di 24 ore.

Classificare i carichi di lavoro e gli obiettivi di RTO/RPO

Le VM dell’applicazione/web ERP e i SQL AG sono contrassegnati come Tier 1 (RTO 1h, RPO 15m). Il middleware e i servizi file sono Tier 2/3.
Perché: Assicura che gli obiettivi più stringenti guidino le scelte di replica e orchestrazione.

Implementare ASR per i tier ERP su Hyper-V

Installare l’ASR Provider sugli host Hyper-V e registrarli in un insieme di credenziali di Servizi di ripristino (Recovery Services vault). Creare una policy di replica con una soglia RPO di 15 minuti, snapshot coerenti con l’applicazione ogni ora e una conservazione di 48 ore. Abilitare un gruppo di coerenza multi-VM per i server applicativi ERP che condividono transazioni con il listener SQL.
Perché: La replica continua e i checkpoint coerenti con l’applicazione consentono di raggiungere l’RPO di 15 minuti mantenendo la coerenza del tier.

Implementare ASR per il middleware VMware

Distribuire un configuration server on-premise, con un process server collocato nella stessa sede e dimensionato per il churn (tasso di modifica) previsto. Aggiungere un process server di tipo scale-out nel sito più grande. Installare il Mobility Service sulle VM protette. Preparare un master target server per l’eventuale failback.
Perché: L’architettura ASR per VMware fornisce un’acquisizione affidabile delle modifiche e un percorso controllato per il failback quando il sito on-premise viene ripristinato.

Orchestrazione con piani di ripristino e runbook

Costruire un piano di ripristino che raggruppi SQL (dati), poi i tier applicativi dell’ERP, e infine i tier web. Inserire runbook di Azure Automation per: riconfigurare gli NSG, aggiornare le zone DNS private affinché puntino agli IP di Azure e commutare gli endpoint di Traffic Manager. Aggiungere un passaggio di convalida manuale prima di portare online il livello web.
Perché: L’automazione riduce l’RTO e l’errore umano durante una crisi, imponendo il corretto ordine di avvio e lo stato della rete.

Proteggere SQL Server con AG ottimizzati per sito

Mantenere il primario e un secondario in commit sincrono all’interno della stessa area metropolitana per un RPO quasi nullo; mantenere un secondario di DR distante in commit asincrono. Configurare il failover automatico tra le repliche sincrone con il rilevamento dello stato di integrità del database abilitato. Integrare i passaggi di failover dell’AG nel piano di ripristino di ASR per una visibilità incrociata.
Perché: I Gruppi di Disponibilità (AG) sincroni forniscono l’RPO più basso per il tier di database; ASR fornisce l’orchestrazione del sito attorno ad esso.

Stratificare i backup con Azure Backup

Per i server Windows on-premise che richiedono la protezione di file e dello stato del sistema (System State), distribuire l’agente MARS e configurare policy con backup giornalieri e conservazione 30/52/7 (giornaliera/settimanale/annuale). Archiviare e proteggere la passphrase di crittografia in Azure Key Vault (supportato da HSM). Utilizzare MABS per acquisire immagini BMR per i server applicativi critici, per consentire una ricostruzione completa se necessario. Abilitare l’eliminazione temporanea (soft delete) e il PIN di sicurezza sull’insieme di credenziali (vault).
Perché: Il ripristino a un punto nel tempo (point-in-time) protegge dalla corruzione logica e dai ransomware, completando il failover rapido di ASR.

Rafforzare DFSR e il backup dei servizi file

Rivedere la topologia del gruppo di replica (hub-spoke), assicurarsi che le aree di staging siano dimensionate a 1,5 volte il churn giornaliero e regolare le pianificazioni per mantenere una replica quasi in tempo reale all’interno della regione. Proteggere le condivisioni con MARS/MABS per la conservazione a lungo termine e per i test di ripristino in una posizione alternativa.
Perché: Una corretta ottimizzazione di DFSR soddisfa la disponibilità quotidiana, mentre i backup forniscono la sicurezza del rollback.

Convalidare con failover di test e runbook documentati

Eseguire failover di test trimestrali con ASR in una VNet isolata, convalidare la funzionalità dell’ERP su dati mascherati e misurare l’RTO. Eseguire esercitazioni di ripristino: ripristini in posizione alternativa con MARS e un ripristino BMR completo da MABS in una sandbox.
Perché: Esercitazioni regolari dimostrano la validità del piano, fanno emergere deviazioni (drift) e forniscono alla direzione la prova della conformità con RTO/RPO.

Questo progetto soddisfa gli obiettivi di Fabrikam: ASR offre un RTO inferiore a un’ora, i Gruppi di Disponibilità (AG) di SQL in modalità sincrona minimizzano l’RPO per i database, e Azure Backup con MARS/MABS fornisce un ripristino sicuro a un punto nel tempo e la capacità di ricostruzione completa della macchina. I piani di ripristino e i runbook eliminano l’ambiguità durante gli incidenti, e DFSR rimane ottimizzato per la continuità operativa tra i backup.

← Hyper-V · Tutti i domini · Gestione delle Identità e degli Accessi per Ambienti Ibridi →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →