La progettazione di backup e recovery in AZ-305 non è mai una questione di “quale bottone premere”, ma di allineare RPO, RTO, retention e costo a un requisito di business. L’errore d’esame più comune è proporre una tecnologia prima di aver quantificato quanto dato si può perdere (RPO) e quanto a lungo si può restare fermi (RTO).

Scelta del vault: Recovery Services vs Backup vault

Azure espone due tipi di vault e vanno distinti a colpo d’occhio:

  • Recovery Services vault: copre VM IaaS, Azure Files, SQL Server e SAP HANA in VM, oltre agli agent on-premises (MARS/MABS/DPM). È anche il target di Azure Site Recovery per il DR di VM.
  • Backup vault: copre i workload “moderni” — Azure Blob, Managed Disks, Azure Database for PostgreSQL flexible server e AKS.

Trade-off di governance: consolidare pochi vault per subscription/region semplifica RBAC e policy (pilastro Operational Excellence), ma un vault è vincolato alla region delle risorse protette. Un design enterprise usa tipicamente un vault per region per subscription, con policy centralizzate via Azure Policy per garantire copertura uniforme.

Storage redundancy e cross-region

La redundancy del vault è una decisione di Reliability vs Cost:

  • LRS: più economico, ma nessuna protezione contro disastri regionali.
  • GRS: replica geo-ridondante, prerequisito per il Cross-Region Restore (CRR) — capacità di ripristinare in una region secondaria anche senza failover. Raccomandato per workload di produzione critici.
  • ZRS: resilienza intra-region tra availability zone, senza costi di traffico cross-region.

Regola d’esame: se il requisito cita “recuperare i backup anche se una region va giù”, la risposta è GRS + Cross-Region Restore abilitato, non ASR (che è per il failover del workload live, non per il ripristino del backup).

Policy GFS e retention

Lo schema GFS (Grandfather-Father-Son) modella la retention su livelli daily/weekly/monthly/yearly. Il design deve mappare i requisiti di compliance (es. conservazione fiscale a 7 o 10 anni) sui punti yearly, evitando di gonfiare i punti daily.

Il trade-off centrale è frequenza di backup (RPO) vs costo di storage: aumentare i recovery point riduce l’RPO ma moltiplica lo storage consumato. Un pattern efficiente in ottica Cost Optimization: backup giornalieri con retention breve per il ripristino operativo, e pochi punti mensili/annuali a lunga conservazione per la compliance, sfruttando il tier di Archive dove supportato per abbattere il costo dei punti a lungo termine.

Difese anti-ransomware

L’esame 2026 insiste sul layer di sicurezza del backup (pilastro Security):

  • Soft delete (enhanced): trattiene i dati di backup eliminati per un periodo configurabile, neutralizzando la cancellazione malevola. È attivo di default.
  • Immutable vault: rende i recovery point non modificabili e non cancellabili prima della scadenza retention — barriera contro attacchi che tentano di ridurre la retention.
  • Multi-user Authorization (MUA) via Resource Guard: operazioni critiche (disabilitare soft delete, ridurre retention, stop protection con delete) richiedono l’approvazione di un secondo principal, tipicamente in una subscription/tenant separato governato da Microsoft Entra ID PIM. Separa il ruolo di backup admin da quello di security admin.

Il layering corretto è: soft delete + immutable vault + MUA, integrato con il monitoraggio degli alert su Microsoft Defender for Cloud e Microsoft Sentinel per rilevare pattern di manomissione dei backup.

Trappole tipiche d’esame

  • Requisito: “ripristinare i backup delle VM in una region diversa in caso di disastro regionale” → Recovery Services vault con storage GRS e Cross-Region Restore abilitato; NON confondere con Azure Site Recovery, che replica il workload attivo per il failover, non i recovery point.
  • Requisito: “impedire che un amministratore compromesso cancelli i backup o ne riduca la retention” → Immutable vault + Multi-user Authorization con Resource Guard in subscription separata; il solo soft delete non basta perché può essere disabilitato.
  • Requisito: “conservare i backup per 7 anni per compliance minimizzando il costo” → policy GFS con punti yearly a lunga retention (non aumentare i punti daily), sfruttando i tier a costo ridotto; verificare che la retention massima della policy copra effettivamente l’intero periodo richiesto.
  • Requisito: “proteggere una Azure File share con RPO di poche ore” → backup di Azure Files nel Recovery Services vault con snapshot multipli al giorno; attenzione perché la retention snapshot ha limiti diversi dalle VM.
  • Requisito: “backuppare Azure Blob e Managed Disk” → serve un Backup vault, non un Recovery Services vault; scambiare i due tipi di vault è l’errore classico sui workload moderni.

Sintesi di design: parti dai numeri (RPO/RTO/retention di compliance), scegli il tipo di vault in base al workload, dimensiona la redundancy sul requisito di DR regionale, e chiudi sempre con il layer anti-ransomware (soft delete + immutable + MUA) prima di ottimizzare il costo.