Backup automatizzati in Istanza gestita di SQL di Azure

  • Articolo

Si applica a:Istanza gestita di SQL di Azure

Questo articolo descrive la funzionalità di backup automatico per Istanza gestita di 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.

Che cosa sono i backup automatici del database?

I backup del database sono elementi essenziali di qualsiasi strategia di continuità aziendale e ripristino di emergenza perché proteggono i dati da danni o eliminazioni. Istanza gestita di SQL di Azure offre backup completamente gestiti e automatizzati del motore di database di SQL Server. Questi backup consentono il ripristino dei database a un determinato punto nel tempo all'interno del periodo di conservazione configurato, fino a un massimo di 35 giorni. Tuttavia, se le regole di protezione dati richiedono che i backup siano disponibili per un lungo periodo di tempo (fino a 10 anni), è possibile configurare la conservazione a lungo termine per i database singoli e in pool.

Frequenza di backup

Istanza gestita di SQL di Azure crea:

La frequenza dei backup del log delle transazioni dipende dalle dimensioni di calcolo e sulla quantità di attività del database. I log delle transazioni vengono eseguiti circa ogni 10 minuti, ma possono variare. Quando si ripristina un database, il servizio determina i backup completi, differenziali e del log delle transazioni da ripristinare, nell’ordine rispettivo.

Ridondanza dell'archivio di backup

Per impostazione predefinita, Istanza gestita di SQL di Azure archivia i dati nei BLOB di archiviazione con ridondanza geografica replicati in un'area associata. La ridondanza geografica consente di proteggere il sistema dalle interruzioni che influiscono sull'archivio di backup nell'area primaria. Consente anche di ripristinare l'istanza in un'area diversa in caso di emergenza.

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 dell'alimentazione e gravi calamità naturali.

Per assicurarsi che i backup rimangano nella stessa area in cui viene distribuito 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. Per altre informazioni sulla ridondanza dell'archiviazione, vedere Ridondanza dei dati.

È possibile configurare la ridondanza dell'archivio di backup quando si crea l'istanza e aggiornarla in un secondo momento a livello di istanza. Le modifiche apportate a un'istanza esistente si applicano solo ai backup futuri. Dopo aver aggiornato la ridondanza dell'archivio di backup di un'istanza esistente, potrebbero essere necessarie fino a 24 ore prima dell'applicazione delle modifiche. Le modifiche apportate alla ridondanza dell'archivio di backup si applicano solo ai backup a breve termine. I criteri di conservazione a lungo termine ereditano l'opzione di ridondanza dei backup a breve termine quando vengono creati i criteri. L'opzione di ridondanza persiste per i backup a lungo termine anche se l'opzione di ridondanza per i backup a breve termine cambia successivamente.

Nota

Si noti che la modifica di ridondanza backup causa un passaggio di aggiornamento che avvia un failover.

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

  • Archiviazione con ridondanza locale (LRS): copia i dati in modo sincrono tre volte all'interno di un'unica posizione fisica nell'area primaria. L'archiviazione con ridondanza locale è l'opzione di replica meno costosa, ma non è consigliata per le applicazioni che richiedono disponibilità o durabilità elevata.

    Diagram showing the locally redundant storage (LRS) option.

  • Archiviazione con ridondanza della zona (ZRS): copia i dati in modo sincrono in tre zone di disponibilità di Azure nell'area primaria. È attualmente disponibile in determinate aree.

    Diagram showing the zone-redundant storage (ZRS) option.

  • L'Archiviazione con ridondanza geografica (GRS) copia i dati 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 in un'unica posizione fisica nell'area secondaria abbinata.

    Il risultato è:

    • Tre copie sincrone nell'area primaria all'interno di una singola zona di disponibilità.
    • Tre copie sincrone nell'area abbinata all'interno di una singola zona di disponibilità copiate dall'area primaria all'area secondaria in modo asincrono.

    Diagram showing the geo-redundant storage (GRS) option.

  • Archiviazione con ridondanza geografica della zona (GZRS): Combina la disponibilità elevata offerta dalla ridondanza tra le zone di disponibilità, con la protezione dalle interruzioni a livello di area fornite dalla replica geografica. I dati vengono copiati in un account dell’archiviazione con ridondanza geografica della zona modo sincrono in tre zone di disponibilità di Azure nell'area primaria. I dati vengono replicati anche in un'area geografica secondaria per la protezione da emergenze a livello di area. In tale area sono disponibili anche tre copie sincrone in una singola zona di disponibilità copiate dall'area primaria all'area secondaria in modo asincrono.

    Diagram showing the geo-zone-redundant storage (GZRS) option.

Avviso

  • Il ripristino geografico viene disabilitato non appena un database viene aggiornato 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 la ZRS o l'archiviazione con ridondanza geografica della zona.

Utilizzo del backup

È possibile usare questi backup per:

  • Ripristinare un database esistente in corrispondenza di un momento 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 nella stessa istanza del database originale o in un'istanza diversa nella stessa sottoscrizione e nella stessa area. Usa un nome diverso per evitare di sovrascrivere il database originale. È anche possibile usare il portale di Azure per ripristinare il backup temporizzato del database in un'istanza di in una sottoscrizione diversa dall'istanza di origine.

    Al termine del ripristino, è possibile eliminare il database originale. In alternativa, è possibile rinominare il database originale e rinominare il database ripristinato usando il nome originale del database.

  • Ripristinare un database eliminato in un punto del tempo all’interno del periodo di conservazione, incluso il momento dell’eliminazione. È possibile ripristinare il database eliminato nella stessa istanza gestita in cui è stato eseguito il backup o un'altra istanza nella stessa sottoscrizione o in una sottoscrizione diversa all'istanza di origine. 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 qualsiasi istanza gestita esistente, 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 di un database, se il database è stato configurato con un criterio di conservazione a lungo termine. La conservazione a lungo termine consente di ripristinare una versione precedente del database mediante il portale di Azure o Azure PowerShell per soddisfare una richiesta di conformità o eseguire una versione precedente dell'applicazione. Per altre informazioni, vedere la pagina panoramica della conservazione a lungo termine.

Ripristinare funzionalità e caratteristiche

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

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

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

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

3 Una soluzione alternativa consiste nell'eseguire il ripristino in un nuovo server e usare Spostamento risorse per spostare il server in un'altra sottoscrizione.

Ripristinare un database dal backup

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

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

Pianificazione dei backup automatici

Istanza gestita di SQL di Azure gestisce automaticamente i backup creando backup completi, differenziali e del log delle transazioni. Questo processo è regolato da una pianificazione interna.

Backup iniziale

  • Nuovi database: subito dopo la creazione, il ripristino o la ridondanza di un database viene modificato, viene avviato il primo backup completo. Questo backup viene in genere completato entro 30 minuti, anche se potrebbe richiedere più tempo per i database di dimensioni maggiori.

  • Database ripristinati: la durata del backup iniziale per i database ripristinati varia in base alle dimensioni del database. I database ripristinati o le copie del database, che sono spesso più grandi, possono richiedere più tempo per il backup iniziale.

Pianificazione backup completo

  • Pianificazione settimanale: il sistema imposta una finestra di backup completo settimanale per l'intera istanza.
  • Finestra backup completo: periodo designato quando vengono eseguiti backup completi. Anche se il sistema mira a completare i backup completi all'interno di questa finestra, se necessario, il backup può continuare oltre il tempo pianificato fino al completamento.
  • Pianificazione adattiva: l'algoritmo di backup valuta l'impatto della finestra di backup sul carico di lavoro circa una volta alla settimana, usando l'utilizzo della CPU e la velocità effettiva di I/O come indicatori. A seconda del carico di lavoro della settimana precedente, è possibile modificare la finestra di backup completa.
  • Configurazione utente: è fondamentale notare che gli utenti non possono modificare o disabilitare la pianificazione del backup.

Importante

Per un nuovo database, 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.

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

La pianificazione del backup di Istanza gestita di SQL di Azure include un backup completo 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 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 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, può essere significativamente inferiore o superiore a seconda della natura dei dati e se la compressione dei dati viene usata nel database.

Importante

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

Istanza gestita di SQL di Azure calcola l'archivio di backup totale conservato come valore cumulativo. Ogni ora questo valore viene segnalato alla pipeline di fatturazione di Azure. La pipeline è 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 escono e vengono eliminati. Dopo l'eliminazione di tutti i backup e il ripristino temporizzato non è più possibile e la fatturazione si arresta.

Importante

I backup per un database eliminato vengono mantenuti per il ripristino temporizzato (PITR), che può aumentare i costi di archiviazione in quanto i backup vengono conservati anche se il database viene eliminato. Per ridurre i costi, è possibile impostare il periodo di conservazione dei backup su 0 giorni, ma solo per i database eliminati. Per i database regolari, il periodo di conservazione minimo è 1 giorno.

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 database individuali. Prendere in considerazione alcune delle tecniche di ottimizzazione seguenti per ridurre l'utilizzo dell'archivio di backup:

  • Ridurre il periodo di conservazione dei backup del database al valore minimo possibile per le esigenze specifiche.
  • Evitare l'esecuzione di operazioni di scrittura di grandi dimensioni, ad esempio ricompilazioni di indici, con una frequenza superiore al necessario.
  • Per operazioni di caricamento di dati di grandi dimensioni, è consigliabile usare indici columnstore cluster e seguire le relative procedure consigliate. Valutare anche la possibilità di ridurre il numero di indici non cluster.
  • Nel livello di servizio 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 al posto delle tabelle permanenti nella logica dell'applicazione per archiviare i risultati o i dati temporanei.
  • Usare l'archivio di backup con ridondanza locale quando possibile, ad esempio ambienti di sviluppo/test.

Conservazione dei backup

Istanza gestita di SQL di Azure consente di eseguire la conservazione a breve termine e a lungo termine dei backup. La conservazione dei backup a breve termine permette il ripristino temporizzato nel periodo di conservazione del database. La conservazione dei backup a lungo termine fornisce i backup per vari requisiti di conformità.

Conservazione a breve termine

Per tutti i database nuovi, ripristinati e copiati, Istanza gestita di SQL di Azure mantiene backup sufficienti per consentire il ripristino temporizzato negli ultimi 7 giorni per impostazione predefinita. Questa configurazione può essere modificata nell'intervallo da 1 a 35 giorni. Il servizio esegue backup completi, differenziali e del log regolari per garantire che i database siano ripristinabili in qualsiasi momento entro il periodo di conservazione definito per l’istanza gestita.

È possibile specificare l'opzione di ridondanza dell'archivio di backup per STR quando si crea l'istanza e quindi modificarla in un secondo momento. Se si modifica l'opzione di ridondanza del backup dopo la creazione dell'istanza, 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. Come descritto in Uso dell'archivio di backup, i backup archiviati per abilitare il ripristino temporizzato potrebbero essere precedenti al periodo di conservazione per garantire un ripristino preciso dei dati.

Se si elimina un database, il sistema mantiene i backup nello stesso modo in cui si farebbe per un database online con il periodo di conservazione specifico. Tuttavia, per un database eliminato, il periodo di conservazione viene aggiornato da 1 a 35 giorni a 0-35 giorni, rendendo possibile eliminare manualmente i backup. Se è necessario mantenere i backup per più tempo del periodo di conservazione a breve termine massimo di 35 giorni, è possibile abilitare la conservazione a lungo termine.

Importante

Se si elimina un'istanza del server di database SQL di Azure, anche tutti i database relativi vengono eliminati e non possono essere recuperati. Non è possibile ripristinare un'istanza gestita eliminata. Tuttavia, se è stata configurata la conservazione a lungo termine per un'istanza gestita, i backup con conservazione a lungo termine non vengono eliminati. È quindi possibile usare questi backup per ripristinare i database in un'istanza gestita diversa nella stessa sottoscrizione, in un momento in cui è stato eseguito un backup con conservazione a lungo termine. Per altre informazioni, vedere Ripristinare il backup a lungo termine.

Conservazione a lungo termine

Con Istanza gestita di SQL, è possibile configurare la conservazione a lungo termine con backup completo per un massimo di 10 anni in Archiviazione BLOB di Azure. Se il criterio LTR è abilitato, i backup completi settimanali vengono copiati automaticamente in un contenitore di archiviazione diverso.

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, Y=0 crea una copia con conservazione a lungo termine mensile. Per altre informazioni sulla conservazione a lungo termine, vedere Conservazione a lungo termine.

La ridondanza dell'archivio di backup con conservazione a lungo termine in Istanza gestita di SQL di Azure viene ereditata dalla ridondanza dell'archivio di backup usata dalla conservazione a breve termine al momento della definizione del criterio di conservazione a lungo termine. Non è possibile modificarla, anche se la ridondanza dell'archivio di backup a breve termine cambia in futuro.

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 dei backup

Istanza gestita di SQL di Azure calcola l'archiviazione totale dei backup fatturabili 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 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 interrotta.

Il prezzo per l'archivio di backup varia. Dipende dall'opzione di ridondanza dell'archivio di backup scelta e dall'area. L'archivio di backup viene addebitata 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
  • Geo-zone-redundant price = published price x 3.4

Per i prezzi, vedere la pagina dei prezzi per Istanza gestita di SQL di Azure.

Nota

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

Per le istanze gestite, le dimensioni totali dell'archivio di backup fatturabile vengono aggregate a livello di istanza e vengono calcolate nel modo seguente:

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

L'archivio di backup fatturabile totale, se presente, viene addebitato in gigabyte al mese per ogni area, in base alla frequenza di ridondanza dell'archiviazione di backup usata. L'utilizzo dell'archivio di backup dipende dal carico di lavoro e dalle dimensioni massime dei singoli database 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. Pertanto, tali database avranno costi di backup più elevati.

Per fare un esempio semplificato, si supponga che un database abbia accumulato un archivio di backup di 744 GB e che tale quantità rimanga costante in un intero mese perché il database dell’azienda è completamente inattivo. Per convertire tale utilizzo cumulativo delle risorse di archiviazione in un utilizzo orario, suddividerlo per 744,0 (31 giorni al mese moltiplicati per le 24 ore di un giorno). Istanza gestita di SQL segnala alla pipeline di fatturazione di Azure che il database ha utilizzato 1 GB di backup del ripristino temporizzato ogni ora, con una frequenza 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 a metà del mese la conservazione del database venga aumentata da 7 a 14 giorni. Questo aumento provocherebbe il raddoppiamento del totale dell'archivio di backup fino a 1,488 GB. Istanza gestita di SQL segnala 1 GB di utilizzo per ore da 1 a 372 (la prima metà del mese). 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/mese. I costi di conservazione non aumentano immediatamente. Aumentano gradualmente ogni giorno, perché i backup aumentano fino a raggiungere il periodo di conservazione massimo di 14 giorni.

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. Il consumo orario dell'archivio di backup varia di conseguenza.

Ciascun backup differenziale contiene anche tutte le modifiche apportate nel 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 riduce quindi bruscamente dopo che un set precedente di backup completi, differenziali e di log perde di validità.

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

  • 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 ridurre le dimensioni di tutti i backup differenziali, backup differenziali troppo grandi che superano i 750 GB e diventano uguali al 75% delle dimensioni del database vengono promossi a backup completi, se l'ultimo backup completo è stato eseguito più di 24 ore fa.

Monitorare i costi

Per ottenere informazioni sui costi dell'archivio di backup, passare a Gestione dei costi e fatturazione nel portale di Azure. Selezionare Gestione costi e quindi selezionare 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 nel modo seguente:

  1. Aggiungere un filtro per Nome servizio.

  2. Nell'elenco a discesa selezionare Istanza gestita di SQL per un'istanza gestita.

  3. Aggiungere un altro filtro per Sottocategoria contatore.

  4. Per monitorare i costi di backup del ripristino temporizzato, nell'elenco a discesa selezionare l'archivio di backup del ripristino temporizzato dell'istanza gestita. I contatori vengono visualizzati solo se esiste un consumo di archivio di backup.

    Per monitorare i costi di backup con conservazione a lungo termine, nell'elenco a discesa selezionare Istanza gestita di SQL - Archivio di backup con conservazione a lungo termine. I contatori vengono visualizzati solo se esiste un consumo di archivio di backup.

Le sottocategorie Archiviazione e calcolo potrebbero risultare interessanti, ma non sono associate ai costi dell'archivio di backup.

Screenshot that shows an analysis of backup storage costs.

Importante

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

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 Istanza gestita di SQL.

Integrità del backup

Tutti i backup del database vengono eseguiti con l'opzione CHECKSUM per fornire un'integrità aggiuntiva del backup. Il test automatico dei backup automatici del database da parte del team di progettazione sql di Azure non è attualmente disponibile per Istanza gestita di SQL di Azure. Pianificare il ripristino del backup di test e DBCC CHECKDB nei database in Istanza gestita di SQL intorno al carico di lavoro.

Anche se il sistema non verifica l'integrità dei backup, esiste ancora una protezione predefinita dei backup che avvisa Microsoft se si verifica un problema con il servizio di backup. Inoltre, Microsoft offre supporto nel caso in cui si verifichi un problema con un backup, ad esempio se non viene eseguito un backup completo, il servizio di backup è bloccato, un backup del log è fuori contratto di servizio o se l'hardware o il software di backup è danneggiato.

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

Se sono presenti 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 l'istanza gestita di SQL usando Criteri di Azure.

Criteri di Azure è un servizio che permette di creare, creare, assegnare e gestire criteri che applicano regole alle risorse di Azure. Criteri di Azure aiuta ad assicurarsi che le risorse rimangano conformi con gli standard aziendali e i contratti di servizio. Per altre informazioni, vedere Panoramica di Criteri di Azure.

Criteri di ridondanza dell'archivio di backup predefiniti

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

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

Conformità

Se il periodo di conservazione predefinito non soddisfa i requisiti di conformità, è possibile modificare il periodo di conservazione di ripristino temporizzato. Per altre informazioni, vedere Modificare il periodo di conservazione del backup con ripristino temporizzato.

Nota

L’articolo Modificare impostazioni backup automatico illustra le procedure per eliminare i dati personali dal dispositivo o dal servizio ed è possibile usare queste informazioni a supporto degli obblighi previsti dal Regolamento generale sulla protezione dei dati (GDPR). Per informazioni generali sul GDPR, vedi la sezione GDPR del Centro protezione Microsoft e la sezione GDPR del Service Trust Portal.

Passaggi successivi