Backup automatici nel database di Azure SQL

Si applica a: Database SQL di Azure

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

Questo articolo descrive la funzionalità di backup automatizzato per Azure SQL Database.

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

Informazioni sul backup del database

I backup del database sono una parte essenziale di qualsiasi strategia di continuità aziendale e ripristino di emergenza, perché consentono di proteggere i dati dal danneggiamento o dall'eliminazione. Questi backup consentono il ripristino del database a un punto nel tempo entro il periodo di conservazione configurato. Se le regole di protezione dei dati richiedono che i backup siano disponibili per un periodo di tempo prolungato (fino a 10 anni), è possibile configurare la conservazione a lungo termine per database singoli e in pool.

Per i livelli di servizio diversi da Hyperscale, Azure SQL Database usa SQL Server tecnologia del motore per eseguire il backup e il ripristino dei dati. I database Hyperscale usano il backup e il ripristino in base agli snapshot di archiviazione. Con la tecnologia di backup SQL Server tradizionale, i database di dimensioni maggiori 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

Azure SQL Database crea:

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

La frequenza esatta 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

Per impostazione predefinita, Azure SQL Database archivia i backup in BLOB di archiviazione con ridondanza geografica replicati in un'area abbinata. La ridondanza geografica consente di proteggersi da interruzioni che influiscono sull'archiviazione di backup nell'area primaria. Consente anche di ripristinare i database in un'area diversa in caso di interruzione a livello di area.

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

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

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

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

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

  

• Archiviazione con ridondanza della zona: copia i backup in modo sincrono tra tre zone di disponibilità di Azure nell'area primaria. Attualmente è disponibile solo in determinate aree.

  

• Archiviazione con ridondanza geografica: copia i backup in modo sincrono tre volte all'interno di una singola posizione fisica nell'area primaria usando l'archiviazione con ridondanza locale. Quindi copia i dati in modo asincrono tre volte in una singola 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 viene aggiornato un database per usare 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 l'archiviazione con ridondanza della zona.
• La ridondanza dell'archiviazione 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'archiviazione 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. Altre informazioni sono disponibili in Backup e ridondanza dell'archiviazione Hyperscale.

Utilizzo del backup

È possibile usare i backup creati automaticamente negli scenari seguenti:

• Ripristinare un database esistente a un punto nel tempo 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, anziché eliminare il database originale, è possibile rinominarlo e quindi rinominare il database ripristinato con il nome del database originale.

• Ripristinare un database eliminato a un punto nel tempo entro il periodo di conservazione, incluso il tempo di eliminazione. 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 perdite di dati.

• Ripristinare un database in un'altra area geografica. Il ripristino geografico consente di eseguire il ripristino da un'interruzione a livello di area quando non è possibile accedere al database o ai backup nell'area primaria. Crea un nuovo database in qualsiasi server esistente in qualsiasi area di Azure.

  Importante

  Il ripristino geografico è disponibile solo per i database configurati con l'archiviazione 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 di un database singolo o in pool, se il database è stato configurato con criteri di conservazione a lungo termine. La conservazione a lungo termine consente di ripristinare una versione precedente del database usando il portale di Azure, l'interfaccia della riga di comando di Azure o Azure PowerShell per soddisfare una richiesta di conformità o per eseguire una versione precedente dell'applicazione. Per altre informazioni, vedere Conservazione a lungo termine.

Funzionalità e funzionalità di ripristino

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

Proprietà di backup	Ripristino temporizzato	Ripristino geografico	Conservazione a lungo termine
Tipi di backup di SQL	Completo, differenziale, log.	Copie replicate dei backup di 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 richiedere più tempo, a seconda delle dimensioni e dell'attività. Vedere Ripristino.	Il ripristino richiede in genere meno di 12 ore, ma potrebbe richiedere più tempo, a seconda delle dimensioni e dell'attività. Vedere Ripristino.	Il ripristino richiede in genere meno di 12 ore, ma potrebbe richiedere più tempo, a seconda delle dimensioni e dell'attività. Vedere Ripristino.
Conservazione	7 giorni per impostazione predefinita, configurabile fino a 35 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 della zona o con ridondanza locale.	Disponibile quando la ridondanza dell'archivio di backup del ripristino temporizzato è impostata su ridondanza geografica. Non disponibile quando l'archiviazione di backup pitr è con ridondanza della zona o con ridondanza locale.	Con ridondanza geografica per impostazione predefinita. È possibile configurare l'archiviazione con ridondanza della zona o con ridondanza locale.
Ripristino di un nuovo database nella stessa area	Supportato	Supportato	Supportato
Ripristino di un nuovo database in un'altra area	Non supportato	Supportato in qualsiasi area di Azure	Supportato in qualsiasi area di Azure
Ripristino di un nuovo database in un'altra sottoscrizione	Non supportato	Non supportato*	Non supportato*
Ripristino tramite portale di Azure	Sì	Sì	Sì
Ripristino tramite PowerShell	Sì	Sì	Sì
Ripristino tramite l'interfaccia della riga di comando di Azure	Sì	Sì	Sì

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

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

La soluzione alternativa consiste nel ripristinare un nuovo server e usare Spostamento risorse per spostare il server in un'altra sottoscrizione oppure usare una copia del database tra sottoscrizioni.

Ripristinare un database dal 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
Modificare la conservazione dei backup	Database SQL Istanza gestita di SQL	Database SQL Istanza gestita di SQL	Database SQL Istanza gestita di SQL
Modificare la conservazione dei backup a lungo termine	Database SQL Istanza gestita di SQL	Database SQL Istanza gestita di SQL	Database SQL Istanza gestita di SQL
Ripristinare un database da un momento all'altro	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 dei backup

Il primo backup completo viene pianificato subito dopo la creazione o il ripristino di un nuovo database. Questo backup viene in genere completato entro 30 minuti, ma può richiedere più tempo quando il database è di grandi dimensioni. Ad esempio, il backup iniziale può richiedere più tempo in un database ripristinato o in una copia del database, che in genere sarebbe più grande di un nuovo database.

Dopo il primo backup completo, tutti i backup aggiuntivi vengono pianificati e gestiti automaticamente. Il momento esatto per l'esecuzione dei backup di database è determinato dal servizio SQL Database in modo da bilanciare il carico di lavoro complessivo del sistema. Non è possibile modificare la pianificazione dei processi di backup o disabilitarli.

Importante

• Per un database nuovo, ripristinato o copiato, la funzionalità di ripristino temporizzato diventa disponibile quando viene creato il backup iniziale del log delle transazioni 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 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 dell'archiviazione di backup

Con SQL Server tecnologia di backup e ripristino, il ripristino di un database a un punto nel tempo richiede una catena di backup ininterrotta. Tale catena è costituita da un backup completo, facoltativamente un backup differenziale e uno o più backup del log delle transazioni.

Azure SQL database pianifica un backup completo ogni settimana. Per fornire ripristino temporizzato nell'intero periodo di conservazione, il sistema deve archiviare backup completi, differenziali e del log delle transazioni aggiuntivi per un massimo di una settimana 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 precedente al periodo di conservazione meno recente. Deve essere presente anche 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 che non sono più necessari per fornire funzionalità di ripristino temporizzato vengono eliminati automaticamente. Poiché i backup differenziali e i backup del log richiedono il ripristino di un backup completo precedente, tutti e tre i tipi di backup vengono eliminati insieme in set settimanali.

Per tutti i database, inclusi i database con crittografia TDE , i backup vengono compressi per ridurre il consumo e i costi di archiviazione di backup. Il rapporto medio di compressione dei backup è compreso tra 3 e 4 volte. Tuttavia, può essere significativamente inferiore o superiore a seconda della natura dei dati e se la compressione dei dati viene usata nel database.

Azure SQL Database calcola il totale dell'archiviazione di backup usata come valore cumulativo. Ogni ora, questo valore viene segnalato alla pipeline di fatturazione di Azure. La pipeline è responsabile dell'aggregazione di questo utilizzo orario per calcolare il consumo alla fine di ogni mese. Dopo l'eliminazione del database, il consumo diminuisce quando i backup e vengono eliminati. Dopo l'eliminazione di tutti i backup e PITR non è più possibile, la fatturazione si arresta.

Importante

I backup di un database vengono conservati per fornire PITR anche se il database è stato eliminato. Anche se l'eliminazione e la ricreazione di un database potrebbero risparmiare costi di archiviazione e calcolo, potrebbe aumentare i costi di archiviazione di 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 Azure SQL Database, l'archiviazione utilizzata da ogni tipo di backup (completo, differenziale e log) viene segnalato nel riquadro di monitoraggio del database come metrica separata. Lo screenshot seguente illustra come monitorare l'utilizzo dell'archiviazione di backup per un singolo database.

Per istruzioni su come monitorare l'utilizzo in Hyperscale, vedere Monitorare l'utilizzo di backup di 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 il consumo di archiviazione di backup:

• Ridurre il periodo di conservazione del backup al minimo per le esigenze.
• Evitare di eseguire operazioni di scrittura di grandi dimensioni, ad esempio la ricompilazione degli indici, più spesso di quanto sia necessario.
• Per operazioni di caricamento di dati di grandi dimensioni, è consigliabile usare indici columnstore cluster e seguire le procedure consigliate correlate. È anche consigliabile ridurre il numero di indici non cluster.
• Nel livello di servizio per utilizzo generico, l'archiviazione dati con provisioning è meno costosa del prezzo dell'archiviazione di backup. Se si hanno continuamente costi elevati di archiviazione di backup in eccesso, è possibile valutare la possibilità di aumentare l'archiviazione dei dati per risparmiare nell'archiviazione di backup.
• Usare tempdb anziché tabelle permanenti nella logica dell'applicazione per archiviare i risultati temporanei o i dati temporanei.
• Usare l'archiviazione di backup con ridondanza locale, ad esempio gli ambienti di sviluppo/test.

Conservazione dei backup

Azure SQL Database offre sia conservazione a breve termine che a lungo termine dei backup. La conservazione a breve termine consente a PITR all'interno del periodo di conservazione per il database. La conservazione a lungo termine fornisce backup per vari requisiti di conformità.

Conservazione a breve termine

Per tutti i database nuovi, ripristinati e copiati, Azure SQL database mantiene backup sufficienti per consentire PITR negli ultimi 7 giorni per impostazione predefinita. Il servizio accetta backup regolari completi, differenziali e log per garantire che i database siano ripristinabili in qualsiasi momento entro il periodo di conservazione definito per il database.

Il backup a breve termine di 1 a 35 giorni per i database Hyperscale è ora disponibile in anteprima. Per altre informazioni, vedere Gestione della conservazione dei backup in Hyperscale.

I backup differenziali possono essere configurati per verificarsi una sola volta in 12 ore o una sola volta in 24 ore. 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 sola volta in 12 ore. Nel modello DTU la frequenza predefinita è una sola volta in 24 ore.

È possibile specificare l'opzione di ridondanza dell'archiviazione 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 lasciati nell'account di archiviazione originale fino alla scadenza del periodo di conservazione, che può essere compreso tra 1 e 35 giorni.

Ad eccezione dei database di base, è possibile modificare il periodo di conservazione dei backup per ogni database attivo nell'intervallo di 1 a 35 giorni. Come descritto in Utilizzo archiviazione backup, i backup archiviati per abilitare PITR potrebbero essere precedenti al periodo di conservazione. Se è necessario mantenere i backup per più tempo rispetto al periodo massimo di conservazione a breve termine 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 sarebbe necessario per un database online con il periodo di conservazione specifico. Non è possibile modificare il periodo di conservazione del backup per un database eliminato.

Importante

Se si elimina un server, tutti i database in tale server vengono eliminati e non possono essere ripristinati. Non è possibile ripristinare un server eliminato. Tuttavia, se è stata configurata la conservazione a lungo termine per un database, i backup LTR non vengono eliminati. È quindi possibile usare questi backup per ripristinare i database in un server diverso nella stessa sottoscrizione, in un momento in cui è stato eseguito un backup LTR. Per altre informazioni, vedere Ripristinare il backup a lungo termine.

Conservazione a lungo termine

Per database SQL, è possibile configurare backup LTR completi per un massimo di 10 anni in Archiviazione BLOB di Azure. Dopo aver configurato il criterio LTR, i backup completi vengono copiati automaticamente in un contenitore di archiviazione diverso ogni settimana.

Per soddisfare vari requisiti di conformità, è possibile selezionare diversi periodi di conservazione per backup completi settimanali, mensili e/o annuali. La frequenza dipende dal criterio. Ad esempio, l'impostazione W=0, M=1 creerebbe una copia LTR mensile. Per altre informazioni su LTR, vedere Conservazione a lungo termine.

L'aggiornamento della ridondanza dell'archiviazione di backup per un database esistente applica la modifica solo ai backup successivi eseguiti in futuro e non per i backup esistenti. Tutti i backup LTR esistenti per il database continueranno a risiedere nel BLOB di archiviazione esistente. I nuovi backup verranno replicati in base alla ridondanza dell'archiviazione 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.

Costi di archiviazione di backup

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

La ridondanza dell'archiviazione 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 i prezzi, vedere la pagina prezzi del database Azure SQL.

Nota

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

Modello DTU

Nel modello DTU non è previsto alcun costo aggiuntivo per l'archiviazione di backup per i database e i pool elastici. Il prezzo dell'archiviazione di backup è una parte del prezzo del database o del pool.

Modello vCore

Azure SQL Database calcola l'archiviazione totale di backup fatturabile come valore cumulativo in 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 il consumo di archiviazione di backup alla fine di ogni mese.

Se un database viene eliminato, l'utilizzo dell'archiviazione di backup diminuisce gradualmente man mano che i backup meno recenti e vengono eliminati. Poiché i backup differenziali e i backup dei log richiedono il ripristino di un backup completo precedente, tutti e tre i tipi di backup vengono eliminati insieme nei set settimanali. Dopo l'eliminazione di tutti i backup, la fatturazione si arresta.

I costi di archiviazione di backup vengono calcolati in modo diverso per i database Hyperscale. Per altre informazioni, vedere Costi di archiviazione di backup hyperscale.

Per i database singoli, viene fornita una quantità di archiviazione di backup pari al 100% delle dimensioni massime di archiviazione dei dati per il database senza alcun costo aggiuntivo. L'equazione seguente viene usata per calcolare l'utilizzo totale dell'archiviazione 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 fornita una quantità di archiviazione di backup pari al 100% dell'archiviazione massima dei dati per le dimensioni di archiviazione del pool senza alcun costo aggiuntivo. Per i database in pool, la dimensione totale dell'archiviazione di backup fatturabile viene aggregata a livello di pool e viene calcolata come segue:

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'archiviazione di backup fatturabile totale, se presente, viene addebitata in gigabyte al mese in base alla frequenza della ridondanza dell'archiviazione di backup usata. Questo consumo di archiviazione di backup dipende dal carico di lavoro e dalle dimensioni di singoli database, pool elastici e istanze gestite. I database fortemente modificati hanno backup differenziali e log più grandi, perché le dimensioni di questi backup sono proporzionali alla quantità di dati modificati. Pertanto, tali database avranno costi di backup più elevati.

Come esempio semplificato, si supponga che un database abbia accumulato 744 GB di archiviazione di backup e che questa quantità rimanga costante per un intero mese perché il database è completamente inattiva. Per convertire questo consumo cumulativo di archiviazione in utilizzo orario, dividerlo per 744.0 (31 giorni al mese volte 24 ore al giorno). database SQL segnala alla pipeline di fatturazione di Azure che il database ha utilizzato 1 GB di backup PITR ogni ora, a una frequenza costante. La fatturazione di Azure aggrega questo consumo e mostra un utilizzo di 744 GB per l'intero mese. Il costo sarà basato sulla tariffa per gigabyte al mese nell'area.

Di seguito è riportato un altro esempio. Si supponga che la conservazione dello stesso database inattiva sia aumentata da 7 giorni a 14 giorni a metà del mese. Questo aumento comporta il raddoppio totale dell'archiviazione di backup a 1.488 GB. database SQL segnala 1 GB di utilizzo per le ore da 1 a 372 (la prima metà del mese). Segnala l'utilizzo come 2 GB per le ore da 373 a 744 (la seconda metà del mese). Questo utilizzo verrà aggregato a una fattura finale di 1.116 GB al mese.

Gli scenari di fatturazione dei backup effettivi sono più complessi. Poiché la frequenza delle modifiche nel database dipende dal carico di lavoro ed è variabile nel tempo, anche le dimensioni di ogni backup differenziale e del log variano. L'utilizzo orario dell'archiviazione di backup varia di conseguenza.

Ogni backup differenziale contiene anche tutte le modifiche apportate nel database dall'ultimo backup completo. Pertanto, le dimensioni totali di tutti i backup differenziali aumentano gradualmente nel corso di una settimana. Si riduce quindi bruscamente dopo che un set precedente di backup completi, differenziali e di log scade.

Si supponga, ad esempio, che un'attività di scrittura intensa, ad esempio una ricompilazione dell'indice, venga eseguita subito dopo il completamento di un backup completo. Le modifiche apportate dalla ricompilazione dell'indice verranno quindi incluse:

• Nei backup del log delle transazioni eseguiti per tutta la durata della ricompilazione.
• Nel backup differenziale successivo.
• In ogni backup differenziale eseguito fino al successivo backup completo.

Per l'ultimo scenario nei database di dimensioni maggiori, un'ottimizzazione nel servizio crea un backup completo anziché un backup differenziale se un backup differenziale è eccessivamente grande in caso contrario. In questo modo si riducono le dimensioni di tutti i backup differenziali fino al backup completo seguente.

È possibile monitorare l'utilizzo totale dell'archiviazione di backup per ogni tipo di backup (completo, differenziale, log delle transazioni) nel tempo, come descritto in Monitorare l'utilizzo.

Monitorare i costi

Per comprendere i costi di archiviazione dei backup, passare a Gestione costi e fatturazione nel portale di Azure. Selezionare Gestione costi e quindi Analisi dei costi. Selezionare la sottoscrizione desiderata per Ambito e quindi filtrare per il periodo di tempo e il servizio a cui si è interessati, come indicato di seguito:

1. Aggiungere un filtro per Nome servizio.

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

3. Aggiungere un altro filtro per la sottocategoria Contatore.

4. Per monitorare i costi di backup pitr, nell'elenco a discesa selezionare l'archiviazione di backup di un pool singolo/elastico per un database singolo o un pool di database elastici. I contatori verranno visualizzati solo se esiste un consumo di archiviazione di backup.

   Per monitorare i costi di backup con conservazione a lungo termine, nell'elenco a discesa selezionare ltr backup storage per un database singolo o un pool di database elastici. I contatori verranno visualizzati solo se esiste un consumo di archiviazione di backup.

Le sottocategorie di archiviazione e calcolo potrebbero interessare anche l'utente, ma non sono associate ai costi di archiviazione di backup.

Importante

I contatori sono visibili solo per i contatori attualmente in uso. Se un contatore non è disponibile, è probabile che la categoria non sia attualmente in uso. Ad esempio, i contatori di archiviazione non saranno visibili per le risorse che non utilizzano l'archiviazione. Se non è presente alcun consumo di archiviazione di backup PITR o LTR, questi contatori non saranno visibili.

Per altre informazioni, vedere Azure SQL Gestione costi del database.

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 ricevono anche controlli di integrità DBCC CHECKDB.

Eventuali problemi rilevati durante un controllo di integrità genereranno un avviso al team di progettazione. Per altre informazioni, vedere Integrità dei dati in database SQL.

Tutti i backup del database vengono eseguiti con l'opzione CHECKSUM per garantire un'integrità aggiuntiva del 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 la conservazione predefinita non soddisfa i requisiti di conformità, è possibile modificare il periodo di conservazione del ripristino temporizzato. Per altre informazioni, vedere Modificare il periodo di conservazione dei backup del ripristino temporizzato.

Nota

L'articolo Modificare le impostazioni di backup automatizzate illustra come eliminare i dati personali dal dispositivo o dal servizio e può essere usato per supportare gli obblighi previsti dal GDPR. Per informazioni generali sul GDPR, vedere la sezione GDPR del Centro protezione Microsoft e la sezione GDPR del portale Service Trust.

Usare Criteri di Azure per applicare la ridondanza dell'archiviazione di backup

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

Criteri di Azure è un servizio che è possibile usare per creare, assegnare e gestire criteri che applicano regole alle risorse di Azure. Criteri di Azure consente di mantenere queste risorse conformi agli standard aziendali e ai contratti di servizio. Per altre informazioni, vedere Panoramica di Criteri di Azure.

Criteri di ridondanza dell'archiviazione di backup predefiniti

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

Per un elenco completo delle definizioni di criteri predefinite per 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.

Passaggi successivi

• Per informazioni su altre soluzioni di continuità aziendale database SQL, vedere Panoramica della 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 in un momento specifico tramite PowerShell.
• Per informazioni su come configurare, gestire e ripristinare dalla conservazione a lungo termine dei backup automatizzati in Archiviazione BLOB di Azure, vedere Gestire la conservazione dei backup a lungo termine.
• Per Istanza gestita di SQL di Azure, vedere Backup automatizzati per Istanza gestita di SQL.