Backup automatizzati in Istanza gestita di SQL di Azure

Si applica a: Istanza gestita di SQL di Azure SQL

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. Con Istanza gestita di SQL di Azure, i backup del motore di database di SQL Server vengono gestiti automaticamente da Microsoft e archiviati in account di archiviazione di Azure gestiti da Microsoft.

Utilizzare questi backup per ripristinare il database in un punto specifico 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 ogni database.

Frequenza di backup

Istanza gestita di SQL di Azure crea:

• Backup completi ogni settimana.
• Backup differenziali ogni 12 ore.
• Backup dei log delle transazioni 10 minuti circa.

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

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

  

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

  

• Archiviazione con ridondanza geografica (GRS): copia i backup in modo sincrono tre volte all'interno di un'unica posizione fisica nell'area primaria usando l'archiviazione con ridondanza locale. Copia quindi i dati in modo asincrono per tre volte in un'unica posizione fisica nell'area secondaria abbinata.

  Il risultato è:

  • Tre copie sincrone nell'area primaria 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.

  

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

  

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.

^{1 Per le applicazioni business critical che richiedono database di grandi dimensioni e che devono garantire la continuità aziendale, usare i} gruppi di failover.
² Tutti i backup con ripristino temporizzato vengono archiviati nell'archiviazione con ridondanza geografica per impostazione predefinita. Di conseguenza, il ripristino geografico è abilitato per impostazione predefinita.
³ I backup dei database eseguiti da istanze configurate con i criteri di aggiornamento di SQL Server 2022 possono essere ripristinati su istanze configurate con i criteri di aggiornamento di SQL Server 2022 o sempre aggiornati. I backup dei database eseguiti da istanze configurate con i criteri di aggiornamento sempre aggiornati possono essere ripristinati solo su istanze anch'esse configurate con i criteri di aggiornamento sempre aggiornati.
⁴ Una soluzione alternativa consiste nell'eseguire il ripristino su un nuovo server e usare Spostamento risorse per spostare il server su un'altra sottoscrizione.

Ripristino del database da un 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.

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.

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, 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 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 backup non più necessari per il ripristino temporizzato vengono eliminati automaticamente. Poiché i backup differenziali e i backup del log richiedono un backup completo precedente per essere ripristinabili, tutti e tre i tipi di backup vengono eliminati insieme in blocchi settimanali.

Per tutti i database, inclusi i database con crittografia TDE, tutti i backup completi e differenziali vengono compressi per ridurre i costi e la compressione dell'archivio di backup. Il rapporto medio di compressione dei backup è da 3 a 4 volte. Tuttavia, questo può diventare notevolmente inferiore o superiore a seconda della natura dei dati e a seconda della compressione dei dati usata nel database.

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 di fatturazione di Azure è responsabile dell'aggregazione dell'utilizzo orario per calcolare il consumo alla fine di ogni mese. Dopo l'eliminazione del database, il consumo diminuisce man mano che i backup perdono di validità e vengono eliminati. Dopo l'eliminazione di tutti i backup e dopo che il ripristino temporizzato non è più possibile, la fatturazione si arresta.

Ottimizzare l'utilizzo dell'archivio di backup

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

• Ridurre il periodo di conservazione dei backup 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 per utilizzo generico le risorse di archiviazione dei dati con provisioning risultano meno dispendiose rispetto al prezzo dell'archivio di archivio di backup. Se i costi dell'archivio di backup in eccesso sono costantemente elevati, è consigliabile prendere in considerazione l'incremento delle risorse di archiviazione dei dati per ottenere risparmi per l'archivio di backup.
• Usare tempdb invece delle tabelle permanenti nella logica dell'applicazione per archiviare i risultati e/o i dati temporanei.
• Usare l'archivio di backup con ridondanza locale quando possibile (ad esempio in ambienti di sviluppo/testing).

Conservazione dei backup

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. Usare la conservazione dei backup a lungo termine per adempiere a requisiti di conformità.

Conservazione a breve termine

Per tutti i database nuovi, ripristinati e copiati, 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.

Conservazione a lungo termine (LTR)

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.

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 la conservazione del database venga aumentata da 7 a 14 giorni a metà del mese. 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 di modifica nel database dipende dal carico di lavoro ed è variabile nel tempo, anche le dimensioni di ogni backup differenziale e del log variano. Il consumo orario dell'archivio di backup varia di conseguenza.

Ciascun backup differenziale contiene anche tutte le modifiche fatte al database dall'ultima volta in cui è stato eseguito un backup completo. Pertanto, le dimensioni totali di tutti i backup differenziali aumentano gradualmente nel corso di una settimana. Si 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, 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 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.

Potrebbero essere interessanti anche le sottocategorie Archiviazione e Calcolo anche se non associate ai costi dell'archivio di backup.

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.

Microsoft è completamente responsabile del mantenimento e della rotazione delle chiavi per i database con chiavi gestite dal servizio (SMK). I backup, PITR o LTR, acquisiti da istanze con TDE con SMK abilitato possono essere ripristinati da Microsoft.

I backup automatici archiviati negli account di archiviazione gestiti da Azure vengono crittografati automaticamente da Archiviazione di Azure. Informazioni sulla crittografia del servizio Archiviazione di Azure per i dati inattivi.

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. L'uso dei Criteri di Azure aiuta ad assicurare che le risorse rimangano conformi agli standard aziendali e ai contratti di servizio. Per altre informazioni, vedere Panoramica di Criteri di Azure.

Criteri di ridondanza dell'archivio di backup predefiniti

Per applicare i requisiti di residenza dei dati a livello di organizzazione, è possibile assegnare criteri a una sottoscrizione usando il portale di Azure o Azure PowerShell. Ad esempio, se si 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.

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.

Passaggi successivi

• Panoramica sulla continuità aziendale
• Gestire la conservazione del backup a lungo termine usando il portale di Azure
• Eseguire il ripristino con backup automatici del database
• Informazioni sull'utilizzo dell'archivio di backup in Istanza gestita di SQL
• Ottimizzare i costi dell'archivio di backup in Istanza gestita di SQL