Backup automatizzati in Istanza gestita di SQL di Azure

Si applica a: Istanza gestita di SQL di Azure

Questo articolo descrive la funzionalità di backup automatizzata per Istanza gestita di SQL di Azure.

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

Nota

Questo articolo illustra come eliminare i dati personali dal dispositivo o dal servizio e può essere usato per supportare gli obblighi previsti dal GDPR. Per informazioni generali sul GDPR, vedere la sezione GDPR del Centro protezione Microsoft e la sezione GDPR del portale di trust del servizio.

Informazioni sul backup del database

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

I database in Istanza gestita di SQL di Azure usano la tecnologia del motore di SQL Server per eseguire il backup e il ripristino dei dati.

Frequenza di backup

Istanza gestita di SQL di Azure crea:

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.

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 dalle interruzioni che influiscono sull'archiviazione di backup nell'area primaria. Consente inoltre 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. Tali eventi possono includere errori hardware temporanei, interruzioni di rete o interruzioni di alimentazione o gravi emergenze naturali.

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

È possibile configurare la ridondanza dell'archiviazione 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'archiviazione di backup di un'istanza esistente, potrebbero essere necessarie fino a 24 ore per l'applicazione delle modifiche. Le modifiche apportate alla ridondanza dell'archiviazione 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 viene creato il criterio. 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.

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

  • Archiviazione con ridondanza locale: copia i backup in modo sincrono tre volte all'interno di una singola posizione fisica nell'area primaria. LRS è l'opzione di replica meno costosa, ma non è consigliabile per le applicazioni che richiedono disponibilità elevata o durabilità.

    Diagramma che mostra l'opzione archiviazione con ridondanza locale.

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

    Diagramma che mostra l'opzione di archiviazione con ridondanza della zona .

  • Archiviazione con ridondanza geografica (GRS): copia i backup in modo sincrono tre volte in una singola posizione fisica nell'area primaria usando LRS. Copia quindi i dati in modo asincrono tre volte in una singola posizione fisica nell'area secondaria associata .

    Il risultato è:

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

    Diagramma che mostra l'opzione archiviazione con ridondanza geografica .

  • Archiviazione con ridondanza geografica della zona (GZRS): combina la disponibilità elevata fornita dalla ridondanza tra zone di disponibilità con protezione dalle interruzioni a livello di area fornite dalla replica geografica. I dati in un account GZRS vengono copiati 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 regionali. In tale area sono disponibili anche tre copie sincrone copiate dall'area primaria all'area secondaria in modo asincrono.

    Diagramma che mostra l'opzione di archiviazione con ridondanza geografica della zona (GZRS).

Avviso

  • Il ripristino geografico viene disabilitato non appena un database viene aggiornato per l'uso dell'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 ZRS o GZRS.

Utilizzo del backup

È possibile usare questi backup per:

  • Ripristinare un database esistente in un momento precedente entro il periodo di conservazione usando l'portale di Azure, l'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 area. Usa un nome diverso per evitare di sovrascrivere il database originale.

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

  • Ripristinare un database eliminato in un momento nel periodo di conservazione, incluso il tempo di eliminazione. È possibile ripristinare il database eliminato solo nella stessa istanza gestita in cui è stato creato il database originale. Prima di eliminare un database, il servizio esegue un backup finale del log delle transazioni per impedire 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. Crea un nuovo database in qualsiasi istanza gestita esistente in qualsiasi area di Azure.

    Importante

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

  • Ripristinare un database da un backup a lungo termine specifico di un database, se il database è stato configurato con un criterio LTR. LTR consente di ripristinare una versione precedente del database usando l'portale di Azure, l'interfaccia della riga di comando di Azure o Azure PowerShell per soddisfare una richiesta di conformità o per eseguire una versione precedente dell'applicazione. Per altre informazioni, vedere Conservazione a lungo termine.

Funzionalità e funzionalità di ripristino

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

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

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

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

La soluzione alternativa consiste nel ripristinare 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 Portale di Azure Interfaccia della riga di comando di Azure Azure PowerShell
Modificare la conservazione dei backup Database SQL
Istanza gestita di SQL
Database SQL
Istanza gestita di SQL
Database SQL
Istanza gestita di SQL
Modificare la conservazione dei backup a lungo termine Database SQL
Istanza gestita di SQL
Database SQL
Istanza gestita di SQL
Database SQL
Istanza gestita di SQL
Ripristinare un database da un momento all'altro Database SQL
Istanza gestita di SQL
Database SQL
Istanza gestita di SQL
Database SQL
Istanza gestita di SQL
Ripristino di un database eliminato Database SQL
Istanza gestita di SQL
Database SQL
Istanza gestita di SQL
Database SQL
Istanza gestita di SQL
Ripristinare un database da Archiviazione BLOB di Azure
Istanza gestita di SQL

Pianificazione dei backup

Il primo backup completo viene pianificato immediatamente dopo la creazione o il ripristino di un nuovo database o dopo la modifica della ridondanza del backup. Questo backup viene in genere completato entro 30 minuti, ma può richiedere più tempo quando il database è di grandi dimensioni.

Per un nuovo database, il backup è veloce. Tuttavia, il tempo di backup può variare per un database ripristinato e dipende dalle dimensioni del database. Ad esempio, il backup iniziale può richiedere più tempo in un database ripristinato o in una copia del database, che in genere sarebbe più grande di un nuovo database.

Dopo il primo backup completo, tutti i backup aggiuntivi vengono pianificati e gestiti automaticamente. La tempistica esatta di tutti i backup del database è determinata dal servizio Istanza gestita di SQL in quanto bilancia il carico di lavoro complessivo del sistema. Non è possibile modificare la pianificazione dei processi di backup o disabilitarli.

Importante

Per un database nuovo, ripristinato o copiato, la funzionalità di ripristino temporizzato diventa disponibile quando viene creato il backup iniziale del log delle transazioni che segue il backup completo iniziale.

Utilizzo dell'archiviazione di backup

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

Istanza gestita di SQL di Azure pianificazioni di backup includono un backup completo ogni settimana. Per fornire ripristino temporizzato nell'intero periodo di conservazione, il sistema deve archiviare backup completi, differenziali e del log delle transazioni aggiuntivi per un massimo di una settimana rispetto al periodo di conservazione configurato.

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

I backup che non sono più necessari per fornire funzionalità di ripristino temporizzato vengono eliminati automaticamente. Poiché i backup differenziali e i backup del log richiedono il ripristino di un backup completo precedente, tutti e tre i tipi di backup vengono eliminati insieme in set settimanali.

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

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

Importante

I backup di un database vengono conservati per fornire PITR anche se il database è stato eliminato. Anche se l'eliminazione e la ricreazione di un database potrebbero risparmiare costi di archiviazione e calcolo, potrebbe aumentare i costi di archiviazione di backup. Il motivo è che il servizio conserva i backup per ogni database eliminato, ogni volta che viene eliminato. Per ridurre i costi di backup, è possibile modificare il periodo di conservazione in 0 giorni, ma è possibile solo per i database eliminati.

Ottimizzare l'utilizzo dell'archivio di backup

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

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

Conservazione dei backup

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

Conservazione a breve termine

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

È possibile specificare l'opzione di ridondanza dell'archiviazione 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, che può essere compreso tra 1 e 35 giorni.

È possibile modificare il periodo di conservazione del backup per ogni database attivo nell'intervallo di 1 a 35 giorni. Come descritto in Utilizzo archiviazione backup, i backup archiviati per abilitare PITR potrebbero essere precedenti al periodo di conservazione.

Se si elimina un database, il sistema mantiene i backup nello stesso modo in cui sarebbe necessario per un database online con il periodo di conservazione specifico. 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 rispetto al periodo massimo di conservazione a breve termine di 35 giorni, è possibile abilitare la conservazione a lungo termine.

Importante

Se si elimina un'istanza gestita, tutti i database in tale istanza gestita vengono eliminati e non possono essere ripristinati. Non è possibile ripristinare un'istanza gestita eliminata. Tuttavia, se è stata configurata la conservazione a lungo termine per un'istanza gestita, i backup LTR 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 LTR. Per altre informazioni, vedere Ripristinare il backup a lungo termine.

Conservazione a lungo termine

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

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

La ridondanza dell'archiviazione di backup LTR in Istanza gestita di SQL di Azure viene ereditata dalla ridondanza dell'archiviazione di backup usata da STR al momento della definizione del criterio LTR. Non è possibile modificarlo, anche se la ridondanza dell'archiviazione di backup STR cambia in futuro.

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

Costi di archiviazione di backup

Istanza gestita di SQL di Azure calcola l'archiviazione totale di backup fatturabile come valore cumulativo in tutti i file di backup. Ogni ora, questo valore viene segnalato alla pipeline di fatturazione di Azure. La pipeline aggrega questo utilizzo orario per ottenere il consumo di archiviazione di backup alla fine di ogni mese.

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

Il prezzo per l'archiviazione di backup varia. Dipende dall'opzione di ridondanza dell'archiviazione di backup scelta e dall'area. L'archiviazione di backup viene addebitata in base ai gigabyte usati al mese, con la stessa frequenza per tutti i backup.

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

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

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

Nota

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

Per le istanze gestite, la dimensione totale dell'archiviazione di backup fatturabile viene aggregata a livello di istanza e viene calcolata come segue:

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

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

Di seguito è riportato un altro esempio. Si supponga che lo stesso database inattiva abbia un aumento della conservazione da 7 giorni a 14 giorni al centro del mese. Questo aumento comporta il raddoppio totale dell'archiviazione di backup a 1,488 GB. Istanza gestita di SQL segnala 1 GB di utilizzo per ore da 1 a 372 (la prima metà del mese). Segnala l'utilizzo come 2 GB per ore da 373 a 744 (seconda metà del mese). Questo utilizzo verrà aggregato a una fattura finale di 1.116 GB al mese. I costi di conservazione non aumentano immediatamente. Aumentano gradualmente ogni giorno, perché i backup aumentano fino a raggiungere il periodo massimo di conservazione 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, le dimensioni di ogni backup differenziale e del log variano anche. L'utilizzo orario dell'archiviazione di backup varia di conseguenza.

Ogni backup differenziale contiene anche tutte le modifiche apportate nel database dall'ultimo backup completo. Quindi, le dimensioni totali di tutti i backup differenziali aumentano gradualmente nel corso di una settimana. Quindi scende in modo nitido dopo un set precedente di backup completi, differenziali e log si estrae.

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

  • Nei backup del log delle transazioni eseguite durante la durata della ricompilazione.
  • Nel backup differenziale successivo.
  • In ogni backup differenziale eseguito fino a quando non si verifica il backup completo successivo.

Per l'ultimo scenario nei database di dimensioni maggiori, un'ottimizzazione nel servizio crea un backup completo anziché un backup differenziale se un backup differenziale sarebbe eccessivamente grande in caso contrario. Ciò riduce le dimensioni di tutti i backup differenziali fino al backup completo seguente.

Monitorare i costi

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

  1. Aggiungere un filtro per il nome del servizio.

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

  3. Aggiungere un altro filtro per la sottocategoria del contatore.

  4. Per monitorare i costi di backup di PITR, nell'elenco a discesa selezionare l'archiviazione di backup del pitr dell'istanza gestita. I contatori verranno visualizzati solo se esiste l'utilizzo dell'archiviazione di backup.

    Per monitorare i costi di backup LTR, nell'elenco a discesa selezionare istanza gestita di SQL - archiviazione di backup ltr. I contatori verranno visualizzati solo se esiste l'utilizzo dell'archiviazione di backup.

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

Screenshot che mostra un'analisi dei costi di archiviazione di backup.

Importante

I contatori sono visibili solo per i contatori attualmente in uso. Se un contatore non è disponibile, è probabile che la categoria non sia attualmente 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 usano l'archiviazione. Se non è presente alcun consumo di archiviazione di backup PITR o LTR, 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 with 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. I test automatici dei backup automatizzati del database da parte del team di progettazione Azure SQL non sono attualmente disponibili 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 supporta se si verifica 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'archiviazione di backup

Se si hanno requisiti di residenza dei dati che richiedono di mantenere tutti i dati in un'unica area di Azure, è possibile applicare backup con ridondanza della zona o ridondanti localmente per l'istanza gestita di SQL usando Criteri di Azure.

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

Criteri di ridondanza dell'archiviazione di backup predefiniti

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

Per un elenco completo delle definizioni dei criteri predefinite per Istanza gestita di SQL, vedere il riferimento ai 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.

Passaggi successivi