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, consultare Recuperare usando i backup automatici del database.

Cos'è un 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 tradizionale di backup SQL Server, i database più grandi hanno lunghi tempi di backup e ripristino. Utilizzando snapshot, Hyperscale offre backup immediato e capacità di ripristino rapido indipendentemente dalla dimensione del database. Per ulteriori informazioni, vedere Hyperscale Backups.

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 esatta dei backup del log delle transazioni dipende dalla dimensione del calcolo e dalla quantità di attività nel database. Quando si ripristina un database, database SQL di Azure determina quali backup completi, differenziali e del log delle transazioni ripristinare.

L'architettura Hyperscale non richiede backup completi, differenziali o di log. Per ulteriori informazioni, vedere Hyperscale Backups.

Ridondanza dell'archivio di backup

Il meccanismo di ridondanza di archiviazione memorizza più copie dei tuoi dati così da essere 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. Puoi sovrascrivere queste impostazioni. 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 dell'archiviazione di backup' per l'uso di un'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 Workload environment modifica anche l'impostazione iniziale per il calcolo, anche se puoi sovrascrivere questa impostazione. In caso contrario, l'opzione Ambiente carico di lavoro non influisce sulle licenze o su altre impostazioni di configurazione del database.

Per assicurarti che i tuoi backup rimangano nella stessa regione in cui il database è distribuito, cambia la ridondanza dello storage di backup dallo storage geo-ridondante predefinito ad altri tipi di storage che mantengono i tuoi dati all'interno della regione. 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.

Puoi configurare la ridondanza dello storage di backup quando crei il database, e aggiornarlo in seguito. Le modifiche che apporti 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. LRS è l'opzione di storage meno costosa, ma non è raccomandato per applicazioni che richiedono resilienza alle interruzioni regionali o una garanzia di elevata durabilità 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 utilizzando l'archiviazione con ridondanza locale (LRS). Copia quindi 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.

  

• Archiviazione con ridondanza di zona geografica (GZRS): L'archiviazione con ridondanza di zona geografica combina la disponibilità elevata fornita dalla ridondanza delle zone di disponibilità (ZRS) con la protezione dalle interruzioni a livello regionale fornita dalla replica geografica (GRS). In GZRS, Azure copia i tuoi backup in modo sincrono attraverso tre zone di disponibilità Azure nella regione primaria, e asincronamente tre volte in una singola posizione fisica nella regione secondaria accoppiata.

  Microsoft consiglia di utilizzare GZRS per le applicazioni che richiedono massima coerenza, durabilità, disponibilità, prestazioni eccellenti e resilienza per il ripristino di emergenza.

  Il risultato è:

  • Tre copie sincrone attraverso le zone di disponibilità, nella regione primaria.

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

    Il diagramma seguente mostra come i dati vengono replicati con GZRS o RA-GZRS:

  

Utilizzo del backup

Usa backup creati automaticamente nei seguenti scenari:

• Ripristinare un database esistente a un momento specifico nel tempo entro il periodo di conservazione dei dati usando il portale di Azure, Azure PowerShell, 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. Puoi ripristinare il database cancellato solo sullo stesso server dove hai creato il database originale. Prima di eliminare un database, database SQL di Azure effettua un backup finale del log delle transazioni per evitare perdite di dati.

• Ripristinare un database in un'altra area geografica. Il geo-restore ti aiuta a recuperare da un'interruzione regionale quando non puoi accedere al tuo database o ai backup nella regione 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 stai usando backup geo-replicati per un database, puoi modificare questa impostazione configurando la ridondanza dello storage di backup.

• Ripristinare un database da uno specifico backup a lungo termine di un singolo database o di un database aggregato, se il database è configurato con una policy LTR. 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 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

Il livello di servizio Business Critical accetta backup automatici da una replica secondaria. 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 eseguiti da una replica secondaria nella maggior parte dei casi. Se un backup automatico fallisce su una replica secondaria, il servizio di backup prende il backup dalla replica primaria.

Backup automatici nelle repliche secondarie:

• Sono abilitati per impostazione predefinita.
• Sono inclusi senza costi aggiuntivi oltre al 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 informazioni sui tempi di ripristino, vedere RTO e RPO.

¹ 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 PITR sono archiviati su archiviazione con ridondanza geografica per impostazione predefinita, quindi il ripristino geografico è abilitato.
³ 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 maggiori informazioni sul ripristino di un database, vedi Ripristina un database da backup. Per esplorare la configurazione di backup e le operazioni di ripristino, usa i seguenti esempi.

Esportare un database

Non puoi scaricare o accedere direttamente ai backup automatici effettuati dal servizio Azure. Azure utilizza questi backup solo per le operazioni di ripristino.

Per esportare un database SQL di Azure, considera altre alternative.

• Quando devi esportare un database per l'archiviazione o per il passaggio a un'altra piattaforma, esporta lo schema del 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. Puoi memorizzare un file BACPAC in Azure Blob storage o in uno storage locale in una sede on-premise. Successivamente, puoi importarla nuovamente in database SQL di Azure, Istanza gestita di SQL di Azure o un'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 programmato subito dopo aver creato o ripristinato un nuovo database. Il completamento del backup richiede in genere 30 minuti, ma potrebbe richiederne di più qualora le dimensioni del database siano elevate. Ad esempio, il backup iniziale può richiedere più tempo su un database restaurato o su una copia del database.

Dopo il primo backup completo, Azure programma e gestisce automaticamente tutti i backup successivi. Il servizio SQL Database determina il momento esatto di tutti i backup del database mentre bilancia 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 fornire PITR all'interno dell'intero periodo di conservazione, Azure deve memorizzare backup completi, differenziali e di transazioni aggiuntivi per un massimo di una settimana in più rispetto al periodo di retention 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 ulteriori informazioni, vedere Pianificazione dei backup Hyperscale.

Azure elimina automaticamente i backup che non sono più necessari per fornire funzionalità PIR. Poiché i backup differenziali e i backup dei log richiedono un backup completo precedente per essere restaurabili, Azure elimina tutti e tre i tipi di backup insieme in set settimanali.

Per tutti i database, inclusi quelli criptati con TDE, Azure comprime tutti i backup completi e differenziali per ridurre la compressione e i costi dello storage di backup. Il rapporto medio di compressione di backup è da tre a quattro 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, Azure riporta questo valore alla pipeline di fatturazione. La pipeline è responsabile dell'aggregazione dell'utilizzo orario per calcolare il consumo entro la fine di ogni mese. Dopo aver eliminato un database, il consumo diminuisce man mano che i backup scadono e vengono cancellati. 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, il pannello di monitoraggio del database riporta lo spazio di archiviazione che ogni tipo di backup (full, differenziale e log) consuma come 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

Non ti viene addebitato il consumo di backup fino alla dimensione massima dei dati di un database. Per ridurre il consumo di storage di backup, considera alcune delle seguenti tecniche di tuning:

• 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 General Purpose, l'archiviazione dati con provisioning è meno costosa rispetto all'archiviazione di backup. Se i costi eccessivi di archiviazione dei backup rimangono costantemente elevati, valuta di aumentare la capacità di archiviazione dei dati per risparmiare sui costi di archiviazione dei 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. La conservazione a lungo termine fornisce backup per vari requisiti di conformità.

Conservazione a breve termine

Per tutti i database nuovi, ripristinati e copiati, database SQL di Azure mantiene di default backup sufficienti per consentire PITR negli ultimi sette giorni. database SQL di Azure effettua regolarmente backup completi, differenziali e di log per garantire che i database siano ripristinabili in qualsiasi momento del periodo di conservazione del database.

Puoi configurare backup differenziali per verificarsi una volta ogni 12 ore o una volta ogni 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 volta ogni 12 ore. Nel modello DTU la frequenza predefinita è una volta ogni 24 ore.

Puoi specificare l'opzione di ridondanza dello storage di backup per STR quando crei il database, e poi cambiarla in seguito. Se cambi l'opzione di ridondanza dei backup su un database esistente, i nuovi backup utilizzano la nuova opzione di ridondanza. Azure non sposta né copia copie di backup fatte con la precedente opzione di ridondanza a breve termine. Azure li lascia nell'account di archiviazione originale fino alla scadenza del periodo di conservazione, che può durare da 1 a 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 elimini un database, Azure mantiene i backup allo stesso modo per un database online con il suo specifico periodo di conservazione. 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. Dopo aver configurato la policy LTR, Azure copia automaticamente i backup completi su un altro container di archiviazione ogni settimana.

Per soddisfare vari requisiti di conformità, si selezionano diversi periodi di conservazione per backup completi settimanali, mensili e annuali. La frequenza dipende dalla politica. Ad esempio, l'impostazione di W=0, M=1 crea una copia LTR ogni mese. Per altre informazioni sulla conservazione a lungo termine, vedere Conservazione a lungo termine.

L'aggiornamento della ridondanza dello storage di backup per un database esistente applica la modifica solo ai backup successivi effettuati in futuro e non a quelli esistenti. Tutti i backup di conservazione a lungo termine esistenti per il database continueranno 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 scelta e dai periodi di conservazione dei backup a lungo termine (LTR). Usa il calcolatore di prezzi LTR per stimare il costo dello storage LTR.

Quando si ripristina un database Hyperscale da un backup LTR, la proprietà di scalabilità della lettura è disabilitata. Per abilitare la lettura scala nel database ripristinato, aggiornare il database dopo che è stato creato. È necessario specificare l'obiettivo del livello di servizio desiderato quando si ripristina da un backup a lungo termine.

Puoi abilitare la conservazione a lungo termine per 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. Si prega di contattare il supporto Microsoft per abilitare la ritenzione a lungo termine dei backup." In tal caso, contatta il supporto Microsoft e crea un ticket di supporto per risolvere la situazione.

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. Paghi per lo storage di backup in base ai gigabyte consumati al mese, alla stessa tariffa per tutti i backup.

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

Modello DTU

Nel modello DTU, per database ed elastic pool non c'è alcun costo aggiuntivo per lo storage di backup PITR per la conservazione predefinita di sette giorni e oltre. Il prezzo dello storage di backup PITR fa parte del prezzo del database o del pool.

Nel modello DTU, si paga per lo storage di backup LTR per database e pool elastici in base allo storage effettivamente consumato dai backup LTR.

Modello vCore

database SQL di Azure calcola il totale della memoria di backup fatturabile come valore cumulativo su tutti i file di backup. Ogni ora, Azure invia questo valore alla pipeline di fatturazione. La pipeline aggrega questi dati di utilizzo orario per determinare il consumo di spazio di archiviazione per i backup alla fine di ogni mese.

Se elimini un database, il consumo di spazio di backup diminuisce gradualmente man mano che i backup più vecchi diventano obsoleti e vengono cancellati. Poiché i backup differenziali e i backup dei log richiedono un backup completo precedente per essere restaurabili, Azure elimina tutti e tre i tipi di backup insieme in set settimanali. Dopo l'eliminazione di tutti i backup, la fatturazione viene arrestata.

I database hyperscale utilizzano un metodo diverso per calcolare i costi di archiviazione di backup. Per altre informazioni, vedere Costi dell’archivio di backup Hyperscale.

Per i database singoli, ottieni una quantità di backup pari alla dimensione massima di archiviazione dei dati per il database senza costi aggiuntivi. La seguente equazione calcola l'utilizzo totale dello storage 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, ottieni una quantità di archiviazione di backup pari al massimo di archiviazione dati per la dimensione del pool senza costi aggiuntivi. 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

Paghi la quantità totale di archiviazione di backup fatturabile, se ce n'è una, in gigabyte al mese secondo la ridondanza dello storage di backup. 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.

Come esempio semplificato, supponiamo che un database accumuli 744 GB di storage di backup e che questa quantità rimanga costante per un intero mese perché il database è completamente inattivo. 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 PITR ogni ora, ad un ritmo costante. La fatturazione Azure aggrega questo consumo e mostra un utilizzo di 744 GB per l'intero mese. Il costo è basato sulla tariffa per gigabyte al mese nell'area geografica.

Di seguito è riportato un altro esempio. Supponiamo che il periodo di conservazione del database venga aumentato 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 riporta 1 GB di utilizzo per le ore 1 fino a 372 (la prima metà del mese). Riporta l'uso come 2 GB per le ore 373 fino a 744 (la seconda metà del mese). Questo consumo si aggrega a una fattura finale di 1.116 GB al mese.

Gli scenari di fatturazione dei backup effettivi sono in realtà più complessi. Poiché la velocità di cambiamento nel database dipende dal carico di lavoro ed è variabile nel tempo, varia anche la dimensione di ogni backup differenziale e di log. 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 vecchio set di backup completi, differenziali e di log diventa obsoleto.

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 ricostruzione dell'indice sono incluse:

• Nei backup del log delle transazioni effettuati nel corso della ricompilazione.
• Nel backup differenziale successivo.
• In ogni backup differenziale eseguito fino a quando non viene eseguito il successivo backup completo.

Per quest'ultimo scenario, in database più grandi, un'ottimizzazione in Azure crea un backup completo invece di un backup differenziale se altrimenti sarebbe eccessivamente grande. Questa ottimizzazione riduce la dimensione di tutti i backup differenziali fino al successivo backup completo.

È 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 dello spazio di archiviazione 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 dello spazio di archiviazione 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 cripti il tuo database usando TDE, i backup vengono automaticamente criptati a riposo, inclusi quelli LTR. 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 nel database SQL.

Integrità del backup

database SQL di Azure gestisce automaticamente determinati tipi di corruzione dei dati utilizzando tecniche integrate quando necessario, senza alcuna perdita di dati. In database SQL di Azure, SQL motore di database esegue la verifica delle pagine durante i backup gestionati dai servizi e durante ogni operazione di ripristino. Gli eventuali problemi rilevati durante il controllo integrità determinano la generazione di un avviso per il team di progettazione.

Come ulteriore livello di protezione, puoi testare il ripristino dei backup ed eseguire controlli di integrità. Per maggiori informazioni, consulta Data Integrity in database SQL di Azure.

Tutti i backup del database utilizzano l'opzione CHECKSUM di fornire maggiore integrità del backup.

Protezione dei backup

Gli abbonamenti Azure di proprietà Microsoft gestiscono i backup di database SQL di Azure utilizzando account Archiviazione di Azure interni e sicuri. Non puoi accedere a questi backup esternamente, quindi offrono un forte isolamento e protezione dei dati. All'interno di Microsoft, solo i servizi backend possono accedere, creare, copiare o ripristinare questi backup. I tecnici Microsoft, inclusi gli sviluppatori, non hanno accesso permanente. Per ridurre al minimo l'esposizione e ottimizzare la sicurezza, Microsoft può ottenere l'accesso Just-In-Time (JIT) solo sotto rigorosi controlli di revisione, solo quando è assolutamente necessario per risolvere problemi specifici dei clienti.

I backup vengono eliminati automaticamente dopo la scadenza del periodo di conservazione.

Conformità tramite conservazione dei backup

Se la ritenzione predefinita non soddisfa i tuoi requisiti di conformità, cambia il periodo di conservazione PITR. Per ulteriori informazioni, consultare Modificare il periodo di conservazione del backup PITR (Point In Time Recovery).

Quando migri il tuo database da un livello di servizio basato su DTU a uno basato su vCore, la migrazione preserva la ritenzione PITR per garantire che la politica di recupero dati della tua applicazione non venga compromessa.

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

Se hai requisiti di residenza dei dati che richiedono di mantenere tutti i tuoi dati in una singola regione Azure, puoi imporre backup ridondanti a zona o localmente ridondanti per il tuo database SQL usando 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. Criteri di Azure ti aiuta a mantenere queste risorse conformi agli standard aziendali e agli accordi di livello di servizio. Per altre informazioni, vedere Panoramica di Criteri di Azure.

Criteri di ridondanza dell'archivio di backup integrati

Per imporre i requisiti di residenza dei dati a livello organizzativo, assegna le policy a un abbonamento utilizzando il portale Azure o Azure PowerShell.

Ad esempio, se abiliti la politica "Azure SQL DB dovrebbe evitare di usare il backup GRS", gli utenti non possono creare database con lo storage predefinito come storage globalmente ridondante. La policy impedisce agli utenti di utilizzare GRS e restituisce il messaggio di errore "Configuring backup storage account type to 'Standard_RAGRS' failed during Database creation or update."

Per un elenco completo delle definizioni di policy integrate per SQL Database, consulta il riferimento alle policy.

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.