backup automatici nel database SQL di Azure

Si applica a: Database 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.

  

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).

Backup automatici nelle repliche secondarie

I backup automatici vengono ora eseguiti da una replica secondaria nel livello di servizio Business Critical. Poiché i dati vengono replicati tra processi di SQL Server in ogni nodo, il servizio di backup esegue il backup dalle repliche secondarie non leggibili. Questa progettazione garantisce che la replica primaria rimanga dedicata al carico di lavoro principale e che la replica secondaria leggibile sia dedicata ai carichi di lavoro di sola lettura. I backup automatici nel livello di servizio Business Critical vengono ora eseguiti da una replica secondaria. Se un backup automatico ha esito negativo in una replica secondaria, il servizio di backup esegue il backup dalla replica primaria.

Backup automatici nelle repliche secondarie:

• Sono abilitati per impostazione predefinita.
• Sono inclusi senza costi aggiuntivi oltre il prezzo del livello di servizio.
• Migliorare le prestazioni e la prevedibilità per il livello di servizio Business Critical.

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.

¹ 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 su un nuovo server e usare Sposta risorse per spostare il server su un'altra sottoscrizione o usare una copia del 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.

Esportare un database

I backup automatici eseguiti dal servizio di Azure non sono disponibili per il download o l'accesso diretto. Possono essere usati solo per le operazioni di ripristino tramite Azure.

Esistono alternative per esportare un database SQL di Azure. Quando è necessario esportare un database per l'archiviazione o lo spostamento in un'altra piattaforma, è possibile esportare lo schema di database e i dati in un file BACPAC. Un file BACPAC è un file ZIP con estensione BACPAC contenente i metadati e i dati del database. È possibile memorizzare il file BACPAC in Archivio BLOB di Azure o in un archivio locale e successivamente importarlo nuovamente in database SQL di Azure, Istanza gestita di SQL di Azure o Istanza di SQL Server.

È possibile importare o esportare un database SQL di Azure usando il collegamento privato o importare o esportare un database SQL di Azure senza consentire ai servizi di Azure di accedere al server.

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.

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 inferiore o superiore a seconda della natura dei dati e a seconda della compressione dei dati usata nel database.

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.

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 per un database online conservazione il periodo di conservazione specifico. Non è possibile modificare il periodo di conservazione dei backup per un database eliminato.

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.

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.

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.

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.

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.

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 abilita il criterio "Il DB SQL di Azure deve evitare di usare il backup di archiviazione con ridondanza geografica", i database non possono essere creati con l'archiviazione predefinita come archiviazione con ridondanza globale e gli utenti non potranno usare l'archiviazione con ridondanza geografica con il messaggio di errore "Configurazione del tipo di account di archiviazione di backup in "Standard_RAGRS" non riuscito durante la creazione o l'aggiornamento del database."

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

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.