backup automatici nel database SQL di Azure

Si applica a:database SQL di Azure

• Database SQL di Azure
• Istanza gestita di SQL di Azure

Questo articolo descrive la funzionalità di backup automatico per i database SQL di Azure.

Per modificare le impostazioni di backup, vedere Modificare le impostazioni. Per ripristinare un backup, vedere Recuperare un database usando i backup automatici del database.

Informazioni sul backup del database

I backup del database sono elementi essenziali di qualsiasi strategia di continuità aziendale e ripristino di emergenza perché aiutano a proteggere i dati da danni o eliminazioni. Questi backup permettono di abilitare la funzionalità di ripristino database a un determinato punto nel tempo all'interno del periodo di conservazione configurato. Se le regole di protezione dei dati richiedono che i backup siano disponibili per un lungo periodo di tempo (fino a 10 anni), è possibile configurare una conservazione a lungo termine (LTR) sia per i database singoli che per quelli in pool.

Per i livelli di servizio diversi da Hyperscale, database SQL di Azure usa la tecnologia del motore SQL Server per eseguire il backup e il ripristino dei dati. I database Hyperscale usano il backup e ripristino mediante snapshot di archiviazione. Con la tecnologia di backup tradizionale di SQL Server, i database di grandi dimensioni hanno tempi di backup/ripristino lunghi. Con l'uso degli snapshot, Hyperscale offre funzionalità di backup istantaneo e ripristino rapido indipendentemente dalle dimensioni del database. Per altre informazioni, vedere Backup hyperscale.

Frequenza di backup

Database SQL di Azure crea:

• Backup completi ogni settimana.
• Backup differenziali ogni 12 o 24 ore.
• I backup dei log delle transazioni vengono eseguiti ogni 10 minuti.

La frequenza dei backup del log delle transazioni è basata sulle dimensioni di calcolo e sulla quantità di attività del database. Quando si ripristina un database, il servizio determina i backup completi, differenziali e del log delle transazioni da ripristinare.

L'architettura Hyperscale non richiede backup completi, differenziali o di log. Per altre informazioni, vedere Backup hyperscale.

Ridondanza dell'archivio di backup

Il meccanismo di ridondanza dell'archiviazione archivia più copie dei dati in modo che siano protetti da eventi pianificati e non pianificati. Questi eventi possono includere errori hardware temporanei, interruzioni della rete o dell'alimentazione e gravi calamità naturali.

Per impostazione predefinita, nei nuovi database SQL di Azure vengono archiviati i backup in BLOB di archiviazione con ridondanza geografica che vengono replicati in un'area abbinata. La ridondanza geografica aiuta a proteggere dalle interruzioni che influiscono sull'archivio di backup nell'area primaria. Consente anche di ripristinare i database in un'area diversa in caso di interruzione a livello di area.

Il portale di Azure offre un'opzione di ambiente del carico di lavoro che aiuta a pre-impostare alcune impostazioni di configurazione. Queste impostazioni possono essere escluse. Questa opzione si applica solo alla pagina Crea database SQL del portale.

• La scelta dell'ambiente del carico di lavoro di sviluppo imposta l'opzione Ridondanza archivio di backup per l'uso dell'archiviazione con ridondanza locale. L'archiviazione con ridondanza locale comporta un costo inferiore ed è appropriata per gli ambienti di pre-produzione che non richiedono la ridondanza dell'archiviazione con replica geografica o di zona.
• Se si sceglie l'ambiente del carico di lavoro Produzione, la ridondanza dell'archivio di backup viene impostata sull'archiviazione con ridondanza geografica, ovvero l'impostazione predefinita.
• L'opzione Ambiente carico di lavoro modifica anche l'impostazione iniziale per il calcolo, anche se questa opzione può essere esclusa. In caso contrario, l'opzione Ambiente carico di lavoro non influisce sulle licenze o su altre impostazioni di configurazione del database.

Per assicurarsi che i backup rimangano nella stessa area in cui viene implementato il database, è possibile modificare la ridondanza dell'archivio di backup dall'archiviazione con ridondanza geografica predefinita ad altri tipi di archiviazione che mantengono i dati all'interno dell'area. La ridondanza dell'archivio di backup configurata viene applicata sia ai backup con conservazione a breve termine (STR) sia ai backup con conservazione a lungo termine (LTR). Per altre informazioni sulla ridondanza dell'archiviazione, vedere Ridondanza dei dati.

È possibile configurare la ridondanza dell'archivio di backup quando si crea il database ed è possibile aggiornarla in un secondo momento. Le modifiche apportate a un database esistente si applicano solo ai backup futuri. Dopo aver aggiornato la ridondanza dell'archivio di backup di un database esistente, le modifiche potrebbero richiedere fino a 48 ore per essere applicate.

È possibile scegliere una delle ridondanze di archiviazione seguenti per i backup:

• Archiviazione con ridondanza locale (LRS): copia i backup in modo sincrono tre volte all'interno di un'unica posizione fisica nell'area primaria. L'archiviazione con ridondanza locale è l'opzione di archiviazione meno dispendiosa, ma non è consigliabile per le applicazioni che richiedono resilienza alle interruzioni a livello di area o la garanzia di durabilità elevata dei dati.

  

• Archiviazione con ridondanza della zona (ZRS): copia i backup in modo sincrono in tre zone di disponibilità di Azure nell'area primaria. Questa opzione + attualmente disponibile solo in alcune aree.

  

• Archiviazione con ridondanza geografica (GRS): copia i backup in modo sincrono tre volte all'interno di un'unica posizione fisica nell'area primaria usando l'archiviazione con ridondanza locale. Copia quindi i dati in modo asincrono per tre volte in un'unica posizione fisica nell'area secondaria abbinata.

  Il risultato è:

  • Tre copie sincrone nell'area primaria.
  • Tre copie sincrone nell'area abbinata copiate dall'area primaria all'area secondaria in modo asincrono.

  

Avviso

• Il ripristino geografico viene disabilitato non appena un database viene aggiornato affinché usi l'archiviazione con ridondanza locale o con ridondanza della zona.
• I diagrammi di ridondanza dell'archiviazione mostrano tutte le aree con più zone di disponibilità (multi-az). Esistono tuttavia alcune aree che forniscono solo una singola zona di disponibilità e non supportano la ZRS.
• La ridondanza dell'archivio di backup per i database Hyperscale può essere impostata solo durante la creazione. Non è possibile modificare questa impostazione dopo il provisioning della risorsa. Per aggiornare le impostazioni di ridondanza dell'archivio di backup per un database Hyperscale esistente con tempi di inattività minimi, usare la replica geografica attiva. In alternativa, è possibile usare la copia del database. Per altre informazioni, vedere Backup hyperscale e ridondanza di archiviazione.

Utilizzo del backup

È possibile usare i backup creati automaticamente negli scenari seguenti:

• Ripristinare un database esistente a un momento nel tempo precedente entro il periodo di conservazione usando il portale di Azure, Azure PowerShell, l'interfaccia della riga di comando di Azure o l'API REST. Questa operazione crea un nuovo database nello stesso server del database originale, ma usa un nome diverso per evitare di sovrascrivere il database originale.

  Al termine del ripristino, è possibile eliminare facoltativamente il database originale e rinominare il database ripristinato con il nome del database originale. In alternativa, invece di eliminare il database originale, è possibile rinominarlo e quindi rinominare il database ripristinato con il nome del database originale.

• Ripristinare un database eliminato a un momento indietro nel tempo all’interno del periodo di conservazione, incluso il momento in cui è stato eliminato. Il database eliminato può essere ripristinato solo nello stesso server in cui è stato creato il database originale. Prima di eliminare un database, il servizio esegue un backup finale del log delle transazioni per evitare la perdita di dati.

• Ripristinare un database in un'altra area geografica. Il ripristino geografico consente di eseguire un ripristino in caso di emergenza geografica quando non è possibile accedere al database o ai backup nell'area primaria. Viene creato un nuovo database in un qualsiasi server in qualunque area di Azure.

  Importante

  Il ripristino geografico è disponibile solo per i database configurati con archivio di backup con ridondanza geografica. Se attualmente non si usano backup con replica geografica per un database, è possibile modificare questa impostazione configurando la ridondanza dell'archivio di backup.

• Ripristinare un database da un backup a lungo termine specifico in un database singolo o in un database in pool qualora il database sia stato configurato con un criterio di conservazione a lungo termine. La conservazione a lungo termine consente di ripristinare una versione precedente del database usando il portale di Azure o Azure PowerShell, per soddisfare le richieste di conformità o eseguire una versione precedente dell'applicazione. Per altre informazioni, vedere Long-term retention (Conservazione a lungo termine).

Ripristinare funzionalità e caratteristiche

Questa tabella riepiloga le funzionalità e le caratteristiche del ripristino temporizzato (PITR), del ripristino geografico e della conservazione a lungo termine.

Proprietà del backup	Ripristino temporizzato	Ripristino geografico	Conservazione a lungo termine
Tipi di backup di SQL	Log completo e differenziale.	Copie replicate geograficamente più recenti dei backup con ripristino temporizzato.	Solo i backup completi.
Obiettivo del punto di ripristino (RPO)	10 minuti, in base alle dimensioni di calcolo e alla quantità di attività del database.	Fino a 1 ora, in base alla replica geografica.*	Una settimana (o criteri dell'utente).
Obiettivo del tempo di ripristino (RTO)	Il ripristino richiede in genere meno di 12 ore, ma potrebbe impiegare più tempo in base alle dimensioni e all'attività. Vedere Ripristino.	Il ripristino richiede in genere meno di 12 ore, ma potrebbe impiegare più tempo in base alle dimensioni e all'attività. Vedere Ripristino.	Il ripristino richiede in genere meno di 12 ore, ma potrebbe impiegare più tempo in base alle dimensioni e all'attività. Vedere Ripristino.
Conservazione	7 giorni per impostazione predefinita, configurabili tra 1 e 35 giorni (ad eccezione dei database Basic che sono configurabili tra 1 e 7 giorni).	Abilitato per impostazione predefinita, uguale all'origine.**	Non abilitata per impostazione predefinita. La conservazione è fino a 10 anni.
Archiviazione di Azure	Con ridondanza geografica per impostazione predefinita. Facoltativamente, è possibile configurare l'archiviazione con ridondanza locale o della zona.	Disponibile quando la ridondanza dell'archivio di backup del ripristino temporizzato è impostata su ridondanza geografica. Non disponibile quando l'archivio di backup del ripristino temporizzato prevede l'archiviazione con ridondanza locale o della zona.	Con ridondanza geografica per impostazione predefinita. È possibile configurare l'archiviazione con ridondanza locale o della zona.
Configurare i backup come non modificabili	Non supportato	Non supportato	Non supportato
Ripristino di un nuovo database nella stessa area	Supportato	Supportato	Supportato
Ripristinare un nuovo database in un'altra area	Non supportato	Supportato in qualsiasi area di Azure	Supportato in qualsiasi area di Azure
Ripristinare un nuovo database in un'altra sottoscrizione	Non supportato	Non supportato***	Non supportato***
Ripristinare tramite il portale di Azure	Sì	Sì	Sì
Ripristinare tramite PowerShell	Sì	Sì	Sì
Ripristinare tramite l'interfaccia della riga di comando di Azure	Sì	Sì	Sì

* Per le applicazioni business critical che richiedono database di grandi dimensioni e che devono garantire la continuità aziendale, usare i gruppi di failover.

** Tutti i backup con ripristino temporizzato vengono archiviati nell'archiviazione con ridondanza geografica per impostazione predefinita. Di conseguenza, il ripristino geografico è abilitato per impostazione predefinita.

*** Una soluzione alternativa consiste nell'eseguire il ripristino in un nuovo server e usare Sposta risorse per spostare il server in un'altra sottoscrizione o usare una copia database tra più sottoscrizioni.

Ripristino del database da un backup

Per eseguire un ripristino, vedere Ripristinare un database dai backup. È possibile esplorare le operazioni di configurazione e ripristino del backup usando gli esempi seguenti.

Operazione	Portale di Azure	Interfaccia della riga di comando di Azure	Azure PowerShell
Modifica della conservazione del backup	Database SQL Istanza gestita di SQL	Database SQL Istanza gestita di SQL	Database SQL Istanza gestita di SQL
Modifica della conservazione del backup a lungo termine	Database SQL Istanza gestita di SQL	Database SQL Istanza gestita di SQL	Database SQL Istanza gestita di SQL
Ripristino di un database da un punto indietro nel tempo	Database SQL Istanza gestita di SQL	Database SQL Istanza gestita di SQL	Database SQL Istanza gestita di SQL
Ripristino di un database eliminato	Database SQL Istanza gestita di SQL	Database SQL Istanza gestita di SQL	Database SQL Istanza gestita di SQL

Pianificazione del backup

Il primo backup completo viene pianificato subito dopo la creazione o il ripristino di un nuovo database. Il completamento del backup richiede in genere 30 minuti, ma potrebbe richiederne di più qualora le dimensioni del database siano elevate. Il backup iniziale, ad esempio, può richiedere più tempo per un database ripristinato o una copia del database, i quali potrebbero essere di solito più grandi rispetto a un database nuovo.

Dopo il primo backup completo, l'esecuzione di tutti i successivi backup viene pianificata e gestita automaticamente. Il momento esatto per l'esecuzione dei backup del database è determinato dal servizio di database SQL in modo da bilanciare il carico di lavoro complessivo del sistema. Non è possibile modificare o disabilitare i processi di backup o la loro pianificazione.

Importante

• Per un nuovo database, ripristinato o copiato, la funzionalità di ripristino temporizzato diventa disponibile quando viene creato il backup del log delle transazioni iniziale che segue il backup completo iniziale.
• I database Hyperscale vengono protetti immediatamente dopo la creazione, a differenza di altri database in cui il backup iniziale richiede più tempo. La protezione è immediata anche se il database Hyperscale è stato creato con una grande quantità di dati tramite copia o ripristino. Per altre informazioni, vedere Backup automatizzati di Hyperscale.

Utilizzo delle risorse di archivio di backup

Con la tecnologia di backup e ripristino di SQL Server, il ripristino di un database a un punto indietro nel tempo richiede una catena di backup che non presenti interruzioni. Tale catena è costituita da un backup completo, un backup differenziale facoltativo e uno o più backup del log delle transazioni.

Le pianificazioni dei backup dei database SQL di Azure includono un backup completo per ogni settimana. Per garantire un ripristino temporizzato nell'intero periodo di conservazione, il sistema deve archiviare altri backup completi, differenziali e del log delle transazioni per un massimo di una settimana in più rispetto al periodo di conservazione configurato.

In altre parole, per qualsiasi punto nel tempo durante il periodo di conservazione, deve essere presente un backup completo che sia precedente al periodo di conservazione meno recente. Deve inoltre essere presente una catena ininterrotta di backup differenziali e del log delle transazioni da tale backup completo fino al successivo backup completo.

I database Hyperscale usano un meccanismo di pianificazione dei backup diverso. Per altre informazioni, vedere Pianificazione dei backup hyperscale.

I backup non più necessari per il ripristino temporizzato vengono eliminati automaticamente. Poiché i backup differenziali e i backup del log richiedono un backup completo precedente per essere ripristinabili, tutti e tre i tipi di backup vengono eliminati insieme in blocchi settimanali.

Per tutti i database, inclusi i database con crittografia TDE, tutti i backup completi e differenziali vengono compressi per ridurre i costi e la compressione dell'archivio di backup. Il rapporto medio di compressione dei backup è da 3 a 4 volte. Tuttavia, questo può diventare notevolmente inferiore o superiore a seconda della natura dei dati e a seconda della compressione dei dati usata nel database.

Importante

Per i database con crittografia TDE, i file di backup del log non vengono compressi per motivi di prestazioni. I backup del log per i database senza crittografia TDE vengono compressi.

Il database SQL di Azure calcola l'archivio di backup totale utilizzato come valore cumulativo. Ogni ora, questo valore viene segnalato alla pipeline di fatturazione di Azure. La pipeline di fatturazione di Azure è responsabile dell'aggregazione dell'utilizzo orario per calcolare il consumo alla fine di ogni mese. Dopo l'eliminazione del database, il consumo diminuisce man mano che i backup perdono di validità e vengono eliminati. Dopo l'eliminazione di tutti i backup e dopo che il ripristino temporizzato non è più possibile, la fatturazione si arresta.

Importante

I backup di un database vengono conservati per fornire il ripristino temporizzato anche se il database è stato eliminato. Anche se l'eliminazione e la ricreazione di un database potrebbero ridurre i costi di archiviazione e calcolo, potrebbero allo stesso modo aumentare i costi di archiviazione dei backup. Il motivo è che il servizio conserva i backup per ogni database eliminato, ogni volta che viene eliminato.

Monitorare l'utilizzo

Per i database vCore in database SQL di Azure, l'archiviazione utilizzata da ogni tipo di backup (completo, differenziale e dei log) viene indicata nel riquadro di monitoraggio del database come una metrica separata. Lo screenshot seguente mostra come monitorare l'utilizzo dell'archivio di backup per un database singolo.

Per istruzioni su come monitorare l'utilizzo in Hyperscale, vedere Monitorare l'utilizzo del backup Hyperscale.

Ottimizzare l'utilizzo dell'archivio di backup

L'utilizzo dell'archivio di backup fino alle dimensioni massime dei dati per un database non viene addebitato. L'utilizzo in eccesso dell'archivio di backup dipende dal carico di lavoro e dalle dimensioni massime dei singoli database. Prendere in considerazione alcune delle tecniche di ottimizzazione seguenti per ridurre l'utilizzo dell'archivio di backup:

• Ridurre il periodo di conservazione dei backup al valore minimo possibile per le esigenze specifiche.
• Evitare l'esecuzione di operazioni di scrittura di grandi dimensioni, come la ricompilazione degli indici, con una frequenza superiore al necessario.
• Per operazioni di caricamento dati di grandi dimensioni, è consigliabile usare indici columnstore cluster e seguire le procedure consigliate correlate. Valutare anche la possibilità di ridurre il numero di indici non cluster.
• Nel livello di servizio per utilizzo generico le risorse di archiviazione dei dati con provisioning risultano meno dispendiose rispetto al prezzo dell'archivio di archivio di backup. Se i costi dell'archivio di backup in eccesso sono costantemente elevati, è consigliabile prendere in considerazione l'incremento delle risorse di archiviazione dei dati per ottenere risparmi per l'archivio di backup.
• Usare tempdb invece delle tabelle permanenti nella logica dell'applicazione per archiviare i risultati e/o i dati temporanei.
• Usare l'archivio di backup con ridondanza locale quando possibile (ad esempio in ambienti di sviluppo/testing).

Conservazione dei backup

Database SQL di Azure fornisce sia la conservazione a breve termine che la conservazione a lungo termine dei backup. L’utilizzo della conservazione dei backup a breve termine consente il ripristino temporizzato nel periodo di conservazione del database. Usare la conservazione dei backup a lungo termine per adempiere a requisiti di conformità.

Conservazione a breve termine

Per tutti i database nuovi, ripristinati e copiati, il database SQL di Azure mantiene backup sufficienti a consentire il ripristino temporizzato negli ultimi sette giorni per impostazione predefinita. Il servizio effettua backup completi, differenziali e del log regolari per garantire che i database siano ripristinabili a qualsiasi momento nel tempo entro il periodo di conservazione definito per il database.

I backup differenziali possono essere configurati per essere eseguiti una volta ogni 12 ore o una volta ogni 24. Una frequenza di backup differenziale di 24 ore potrebbe aumentare il tempo necessario per ripristinare il database, rispetto alla frequenza di 12 ore. Nel modello vCore la frequenza predefinita per i backup differenziali è una volta ogni 12 ore. Nel modello DTU la frequenza predefinita è una volta ogni 24 ore.

È possibile specificare l'opzione di ridondanza dell'archivio di backup per STR quando si crea il database e quindi modificarla in un secondo momento. Se si modifica l'opzione di ridondanza del backup dopo la creazione del database, i nuovi backup useranno la nuova opzione di ridondanza. Le copie di backup eseguite con l'opzione di ridondanza STR precedente non vengono spostate o copiate. Vengono lasciate nell'account di archiviazione originale fino alla scadenza del periodo di conservazione, che può essere compreso tra 1 e 35 giorni.

È possibile modificare il periodo di conservazione dei backup per ogni database attivo su un intervallo compreso tra 1 e 35 giorni, ad eccezione dei database Basic che possono essere configurabili su periodi compresi tra 1 e 7 giorni. Come descritto nella sezione Uso dell'archiviazione di backup, i backup archiviati per abilitare il ripristino temporizzato potrebbero essere precedenti al periodo di conservazione. Se è necessario mantenere i backup per un tempo più lungo del periodo di conservazione a breve termine massimo di 35 giorni, è possibile abilitare la conservazione a lungo termine.

Se si elimina un database, il sistema mantiene i backup nello stesso modo in cui lo farebbe per un database online conservazione il periodo di conservazione specifico. Non è possibile modificare il periodo di conservazione dei backup per un database eliminato.

Importante

Se si elimina il server, vengono eliminati anche tutti i database che gli appartengono e non sarà possibile recuperarli. Non è possibile ripristinare un server eliminato. Tuttavia, se è stata configurata la conservazione a lungo termine per un database, i backup con conservazione a lungo termine non vengono eliminati. È quindi possibile usare questi backup per ripristinare i database su un server diverso nella stessa sottoscrizione, al momento nel tempo in cui è stato eseguito il backup con conservazione a lungo termine. Per altre informazioni, vedere Ripristinare un backup a lungo termine.

Conservazione a lungo termine

Per i database SQL è possibile configurare la conservazione a lungo termine (LTR) dei backup completi fino a un massimo di 10 anni in Archiviazione BLOB di Azure. Se il criterio di conservazione a lungo termine è stato configurato, i backup completi vengono copiati automaticamente in un contenitore di Archiviazione diverso con cadenza settimanale.

Per soddisfare i diversi requisiti di conformità, è possibile selezionare periodi di conservazione diversi per backup completi settimanali, mensili e/o annuali. La frequenza dipende dai criteri. Ad esempio, l'impostazione W=0, M=1 crea una copia con conservazione a lungo termine mensile. Per altre informazioni sulla conservazione a lungo termine, vedere Conservazione a lungo termine.

L'aggiornamento della ridondanza dell'archivio di backup per un database esistente applica la modifica solo ai backup successivi eseguiti in momenti futuri e non ai backup esistenti. Tutti i backup di conservazione a lungo termine esistenti per il database continuano a risiedere nel BLOB di archiviazione esistente. I nuovi backup vengono replicati in base alla ridondanza dell'archivio di backup configurata.

Il consumo di archiviazione dipende dalla frequenza e dai periodi dei backup con conservazione a lungo termine. È possibile usare lo strumento di calcolo dei prezzi per la conservazione a lungo termine per stimare il costo di questo tipo di archiviazione.

Quando si ripristina un database Hyperscale da un backup con conservazione a lungo termine, la proprietà di scalabilità in lettura è disabilitata. Per abilitare la scalabilità in lettura nel database ripristinato, aggiornare il database dopo la creazione. È necessario specificare l'obiettivo del livello di servizio di destinazione quando si ripristina da un backup con conservazione a lungo termine.

È possibile abilitare la conservazione a lungo termine anche per i database Hyperscale creati o migrati da altri livelli di servizio. Se si tenta di abilitare la conservazione a lungo termine per un database Hyperscale in cui non è ancora supportata, verrà mostrato l'errore seguente: "Si è verificato un errore durante l'abilitazione della conservazione dei backup a lungo termine per questo database. Contattare il supporto Tecnico Microsoft per abilitare la conservazione dei backup a lungo termine." In questo caso, contattare il supporto tecnico Microsoft e creare un ticket di supporto per risolvere il problema.

Costi di archiviazione dei backup

Il prezzo per l'archivio di backup varia e dipende dal modello di acquisto (DTU o vCore), dall'opzione di ridondanza dell'archivio di backup scelta e dall'area. L'archivio di backup viene addebitato in base ai gigabyte utilizzati al mese, con la stessa tariffa per tutti i backup.

La ridondanza dell'archivio di backup influisce sui costi di backup nel modo seguente:

• Locally redundant price = published price
• Zone-redundant price = published price x 1.25
• Geo-redundant price = published price x 2

Per informazioni sui prezzi, vedere la pagina Database SQL di Azure - Prezzi.

Nota

Una fattura di Azure mostra solo lo spazio occupato per l’archivio di backup in eccesso, non l'intero spazio di archiviazione utilizzato. Ad esempio, in uno scenario ipotetico, se è stato effettuato il provisioning di 4 TB di archiviazione dei dati, si otterranno 4 TB di spazio libero per l’archivio di archivio di backup. Se si usa un totale di 5,8 TB di spazio per l’archivio di backup, la fattura di Azure mostrerà solo 1,8 TB perché viene addebitato solo l'archivio di backup usato in eccesso.

Modello DTU

Nel modello DTU, per i database e i pool elastici non sono previsti costi aggiuntivi per l'archivio di backup PITR per la conservazione predefinita di 7 giorni e oltre. Il prezzo dell'archivio di backup PITR fa parte del prezzo del database o del pool.

Importante

Nel modello DTU, i database e i pool elastici vengono addebitati per l'archivio di backup con conservazione a lungo termine in base allo spazio di archiviazione effettivamente utilizzato dai backup con conservazione a lungo termine.

Modello vCore

Il database SQL di Azure calcola l'archivio di backup totale fatturabile come valore cumulativo tra tutti i file di backup. Ogni ora, questo valore viene segnalato alla pipeline di fatturazione di Azure. La pipeline aggrega questo utilizzo orario per ottenere l'utilizzo dell'archivio di backup alla fine di ogni mese.

Se un database viene eliminato, l'utilizzo dell'archivio di backup diminuisce gradualmente man mano che i backup meno recenti e vengono eliminati. Poiché i backup differenziali e i backup del log richiedono un backup completo precedente per essere ripristinabili, tutti e tre i tipi di backup vengono eliminati insieme in blocchi settimanali. Dopo l'eliminazione di tutti i backup, la fatturazione viene arrestata.

Il costo dell'archivio di backup viene calcolato in modo diverso per i database Hyperscale. Per altre informazioni, vedere Costi dell’archivio di backup Hyperscale.

Per i database singoli viene fornito gratuitamente un archivio di backup equivalente al 100% dello spazio di archiviazione dati massimo del database. L'equazione seguente viene usata per calcolare l'utilizzo totale dell'archivio di backup fatturabile:

Total billable backup storage size = (size of full backups + size of differential backups + size of log backups) – maximum data storage

Per i pool elastici viene fornito gratuitamente un archivio di backup equivalente al 100% dello spazio di archiviazione dati massimo allocato per il pool. Per database in pool, le dimensioni totali dell'archivio di backup fatturabili vengono aggregate a livello di pool e vengono calcolate nel modo seguente:

Total billable backup storage size = (total size of all full backups + total size of all differential backups + total size of all log backups) - maximum pool data storage

L'archivio di backup fatturabile totale, se presente, viene addebitato in gigabyte al mese in base alla frequenza di ridondanza dell'archivio di backup usato. Questo consumo di archiviazione di backup dipende dal carico di lavoro e dalle dimensioni dei singoli database, pool elastici e istanze gestite. I database fortemente modificati hanno backup differenziali e di log più grandi, perché le dimensioni di questi backup sono proporzionali alla quantità di dati modificati. Di conseguenza, tali database hanno costi di backup più elevati.

Prendiamo in esempio un database che accumula un archivio di backup di 744 GB e che tale quantità rimanga costante nel corso di un intero mese poiché il database in questione è del tutto privo di attività. Per convertire tale utilizzo cumulativo delle risorse di archiviazione in un utilizzo orario, suddividerlo per 744,0 (31 giorni al mese moltiplicate per le 24 ore di un giorno). Il database SQL segnala alla pipeline di fatturazione di Azure che il database ha utilizzato 1 GB di backup con ripristino temporizzato ogni ora, a un ritmo costante. La fatturazione di Azure eseguirà l'aggregazione di tale utilizzo e mostrerà un utilizzo pari a 744 GB per l'intero mese. Il costo è basato sulla tariffa per gigabyte al mese nell'area geografica.

Di seguito è riportato un altro esempio. Si supponga che la conservazione del database venga aumentata da 7 a 14 giorni a metà del mese. Questo aumento provocherebbe ipoteticamente il raddoppiamento del totale dell'archivio di backup fino a 1,488 GB. Il database SQL segnalerà 1 GB di utilizzo per le ore comprese tra 1 e 372 (la prima metà del mese). Quindi segnalerà un utilizzo di 2 GB per le ore comprese tra 373 e 744 (la seconda metà del mese). Tale utilizzo verrà aggregato in una fattura finale di 1,116 GB al mese.

Gli scenari di fatturazione dei backup effettivi sono in realtà più complessi. Poiché la frequenza di modifica nel database dipende dal carico di lavoro ed è variabile nel tempo, anche le dimensioni di ogni backup differenziale e del log variano. Il consumo orario dell'archivio di backup varia di conseguenza.

Ciascun backup differenziale contiene anche tutte le modifiche fatte al database dall'ultima volta in cui è stato eseguito un backup completo. Pertanto, le dimensioni totali di tutti i backup differenziali aumentano gradualmente nel corso di una settimana. Si riducono quindi bruscamente dopo che un set precedente di backup completi, differenziali e di log perde validità.

Supponiamo, ad esempio, che un'attività di scrittura intensa, come ad esempio la ricompilazione di un indice, venga eseguita subito dopo il completamento di un backup completo. Le modifiche apportate dalla ricompilazione dell'indice verranno di conseguenza incluse:

• Nei backup del log delle transazioni eseguiti per tutta la durata della ricompilazione.
• Nel backup differenziale successivo.
• In ogni backup differenziale eseguito fino a quando non viene eseguito il backup completo successivo.

Per l'ultimo scenario, per un database di dimensioni maggiori, poniamo che l'ottimizzazione in un servizio crei un backup completo anziché un backup differenziale qualora un backup differenziale possa risultare eccessivamente grande in caso contrario. In questo caso si riducono le dimensioni di tutti i backup differenziali fino al backup completo seguente.

È possibile monitorare l'utilizzo totale dell'archivio di backup per ogni tipo di backup (completo, differenziale, log delle transazioni) nel corso del tempo, come descritto nella sezione Monitorare l'utilizzo.

Monitorare i costi

Per ottenere informazioni sui costi dell'archivio di backup, vedere Gestione dei costi e fatturazione nel portale di Azure. Selezionare Gestione dei costi e quindi Analisi dei costi. Selezionare la sottoscrizione da usare come Ambito e quindi filtrare in base al periodo di tempo e al servizio a cui si è interessati come mostrato di seguito:

1. Aggiungere un filtro per il Nome del servizio.

2. Nell'elenco a discesa, selezionare database SQL per un database singolo o un pool di database elastico.

3. Aggiungere un altro filtro per Sottocategoria contatore.

4. Per monitorare i costi di un backup PITR, selezionare nell’elenco a discesa Archivio di backup PITR singolo/pool elastico per un database singolo o un pool elastico. I contatori vengono mostrati solo se esiste un consumo dell’archivio di backup.

   Per monitorare i costi di backup con conservazione a lungo termine, nell'elenco a discesa selezionare Archivio di backup con conservazione a lungo termine per un database singolo o un pool di database elastico. I contatori vengono mostrati solo se esiste un consumo dell’archivio di backup.

Potrebbero essere interessanti anche le sottocategorie Archiviazione e Calcolo anche se non associate ai costi dell'archivio di backup.

Importante

I contatori sono visibili solo per i contatori attualmente in uso. Se un contatore non è disponibile, è probabile che la categoria non venga attualmente usata. Ad esempio, i contatori di archiviazione non saranno visibili per le risorse che non utilizzano l'archiviazione. Se non è presente alcun consumo di archivio di backup PITR o con conservazione a lungo termine, questi contatori non saranno visibili.

Per altre informazioni, vedere Gestione dei costi database SQL di Azure.

Backup crittografati

Se il database è crittografato con TDE, i backup vengono crittografati automaticamente quando i dati sono inattivi, inclusi i backup con conservazione a lungo termine. Tutti i nuovi database in Azure SQL vengono configurati con la crittografia TDE abilitata per impostazione predefinita. Per altre informazioni su TDE, vedere Transparent Data Encryption con database SQL.

Integrità del backup

In modo continuativo, il team di progettazione di Azure SQL verifica automaticamente il ripristino dei backup automatici dei database. Al momento del ripristino temporizzato, i database sono anche sottoposti a controlli di integrità DBCC CHECKDB.

Gli eventuali problemi rilevati durante il controllo integrità determinano la generazione di un avviso per il team di progettazione. Per altre informazioni, vedere Integrità dei dati nel database SQL.

Tutti i backup del database vengono eseguiti con l'opzione CHECKSUM per garantire un'integrità aggiuntiva al backup.

Conformità

Quando si esegue la migrazione del database da un livello di servizio basato su DTU a un livello di servizio basato sulla vCore, la conservazione con ripristino temporizzato viene preservata per garantire che il criterio di ripristino dei dati dell'applicazione non venga compromesso. Se il periodo di conservazione predefinito non soddisfa i requisiti di conformità, è possibile modificare il periodo di conservazione di ripristino temporizzato. Per altre informazioni, vedere Modificare il periodo di conservazione del backup con ripristino temporizzato.

Nota

L’articolo Modificare le impostazioni di backup automatico illustrano i passaggi da seguire per eliminare i dati personali dal dispositivo o dal servizio e possono essere utili come supporto per riuscire a soddisfare gli obblighi previsti dal Regolamento generale sulla protezione dei dati (GDPR). Per informazioni generali sul GDPR, vedi la sezione GDPR del Centro protezione Microsoft e la sezione GDPR del Service Trust Portal.

Usare i Criteri di Azure per applicare la ridondanza dell'archivio di backup

Se si hanno requisiti di residenza dei dati che richiedono di mantenere tutti i dati in una singola area di Azure, è possibile effettuare backup con ridondanza della zona o con ridondanza locale per il database SQL usando i Criteri di Azure.

I Criteri di Azure sono un servizio che consente di creare, assegnare e gestire criteri che applicano regole alle risorse di Azure. L'uso dei Criteri di Azure aiuta ad assicurare che le risorse rimangano conformi agli standard aziendali e ai contratti di servizio. Per altre informazioni, vedere Panoramica di Criteri di Azure.

Criteri di ridondanza dell'archivio di backup predefiniti

Per applicare i requisiti di residenza dei dati a livello di organizzazione, è possibile assegnare criteri a una sottoscrizione usando il portale di Azure o Azure PowerShell. Ad esempio, se si assegnano i criteri predefiniti seguenti, gli utenti nella sottoscrizione non potranno creare un database con archivio di backup con ridondanza geografica tramite il portale di Azure o Azure PowerShell: è consigliato evitare che il database SQL usi l’archiviazione con ridondanza geografica.

Per un elenco completo delle definizioni di criteri predefiniti per i database SQL, vedere le informazioni di riferimento sui criteri.

Importante

I criteri di Azure non vengono applicati quando si crea un database tramite T-SQL. Per specificare la residenza dei dati quando si crea un database usando T-SQL, usare LOCAL o ZONE come input per il parametro BACKUP_STORAGE_REDUNDANCY nell'istruzione CREATE DATABASE.

Contenuto correlato

• Per informazioni sulle altre soluzioni di continuità aziendale dei database SQL, vedere Informazioni generali sulla continuità aziendale.
• Per modificare le impostazioni di backup, vedere Modificare le impostazioni.
• Per ripristinare un backup, vedere Ripristinare usando i backup o Ripristinare un database a un punto nel tempo usando PowerShell.
• Per informazioni su come configurare, gestire e ripristinare dalla conservazione a lungo termine i backup automatici nell’Archiviazione BLOB di Azure, vedere Gestire la conservazione del backup a lungo termine.
• Per un’Istanza gestita di SQL di Azure, vedere Backup automatici per un’Istanza gestita di SQL.