Chi possiede il backup
Davanti a uno scenario di ripristino la prima domanda non è come si fa il restore, ma di chi è il backup. In Azure SQL Database e in Azure SQL Managed Instance i backup automatici fanno parte del servizio: la piattaforma esegue full, differential e transaction log backup con una propria pianificazione, e non si disattivano. Il DBA configura la conservazione e la backup storage redundancy (locale, di zona, geografica): la ridondanza decide se esiste un punto di ripartenza fuori regione, e pesa sul costo.
Su SQL Server su macchina virtuale Azure e on-premises vale l’opposto: nessuno fa backup al posto tuo. Strategia, pianificazione, destinazione e verifica sono del DBA, tipicamente con SQL Server Agent, oppure delegando ad Azure Backup per SQL Server in VM o all’automated backup dell’estensione SQL IaaS Agent. Attribuire a una VM i backup automatici del PaaS — o cercare di disattivarli su Azure SQL Database — è l’errore che l’esame cerca.
Point-in-time restore e long-term retention
Nei servizi PaaS il point-in-time restore (PITR) è lo strumento principale contro l’errore umano: si sceglie un istante dentro il periodo di conservazione e la piattaforma ricostruisce il database. Due proprietà da ricordare: il restore crea sempre un nuovo database, non sovrascrive l’originale (recuperare una tabella cancellata passa da un ripristino a fianco e dalla copia dei dati indietro), e la stessa meccanica copre il ripristino di un database eliminato, purché si resti dentro la finestra di conservazione e il logical server o l’instance esistano ancora.
La long-term retention (LTR) risponde a un’altra esigenza: obblighi normativi pluriennali. Si definisce una policy su base settimanale, mensile e annuale e i backup selezionati vengono conservati a parte. Il trade-off è la granularità: da LTR si ripristina solo uno dei backup conservati, non un istante qualsiasi, e l’operazione è più lenta del PITR. Non sono alternative: “torniamo a prima dell’incidente di stamattina” contro “dimostriamo com’erano i dati a fine anno”.
Recovery model e catena di ripristino su VM
Su VM e on-premises tutto dipende dal recovery model. In simple il log viene troncato ai checkpoint: niente transaction log backup e quindi nessun ripristino a un istante preciso, si torna al più recente full o differential. In full i log backup sono obbligatori — altrimenti il log cresce senza limite — ed è l’unico modo per avere un point-in-time reale. Il bulk-logged riduce il logging delle operazioni bulk, ma un intervallo che le contiene non è ripristinabile a un istante intermedio.
La catena è ordinata: full, il differential più recente, poi la sequenza dei log backup, tutti applicati lasciando il database in recovery fino all’ultimo, con arresto sull’istante desiderato. Dopo un guasto, se il file di log è leggibile, il primo passo è il tail-log backup: saltarlo significa perdere le transazioni fra l’ultimo backup e l’incidente. Backup e restore possono usare archiviazione cloud (backup to URL verso Azure Blob Storage con credential dedicata), che è anche la via classica per portare un database on-premises su una VM Azure.
Il backup che nessuno ha mai ripristinato
Un backup non verificato non è un backup, è una speranza. Le contromisure fanno parte della strategia: checksum in scrittura, verifica del set di backup e soprattutto un restore di prova periodico su un ambiente separato, con controllo di consistenza via DBCC CHECKDB. È anche l’unico modo per misurare il tempo reale di ripristino, che sulla carta regge sempre.
Trappole tipiche d’esame
- “Ridurre i costi disattivando i backup automatici di Azure SQL Database” → non è possibile: nel PaaS sono strutturali. Le leve reali sono la conservazione per il PITR, la policy LTR e la backup storage redundancy.
- “Recuperare una tabella cancellata due ore fa” → PITR su un nuovo database: il ripristino non sovrascrive l’originale; si ripristina a fianco e si riportano indietro i soli dati necessari, lasciando la produzione online.
- “Conservare lo stato di fine anno per obblighi pluriennali” → LTR, non conservazione PITR: allungare la finestra del point-in-time non è la risposta, e da LTR si ripristina un backup conservato, non un istante arbitrario.
- “Point-in-time restore con recovery model simple” → incompatibile: senza log backup non esiste ripristino a un istante. Serve passare a full e far ripartire la catena con un nuovo full backup.
- “Ripristinare una VM all’istante prima del DELETE sbagliato” → tail-log backup, poi la catena completa: full, differential più recente, log in sequenza con arresto sull’istante; ordine e tail-log sono il punto della domanda.
- “Il backup gira ogni notte senza errori, quindi siamo protetti” → non dimostrato: finché non c’è un restore di prova riuscito con controllo di consistenza, tempo di ripristino e validità dei set restano ipotesi.