È possibile modificare il periodo di conservazione predefinito dei backup a recupero temporizzato (PITR) e la frequenza dei backup differenziali usando il portale di Azure, l'interfaccia della riga di comando di Azure, PowerShell o l'API REST. Gli esempi seguenti illustrano come modificare la conservazione PITR impostandola su un intervallo di 28 giorni e i backup differenziali su uno di 24 ore.
Avviso
Se si riduce il periodo di conservazione corrente, si perde la possibilità di ripristinare a momenti nel tempo precedenti al nuovo periodo di conservazione. I backup che non sono più necessari per fornire ripristino temporizzato entro il nuovo periodo di conservazione vengono eliminati.
Se si aumenta il periodo di conservazione corrente, non si ottiene immediatamente la possibilità di ripristinare a momenti nel tempo precedenti che siano compresi nel nuovo periodo di conservazione. Si ottiene tale possibilità nel tempo, man mano che il sistema inizia a conservare i backup per periodi più lunghi.
Per modificare il periodo di conservazione dei backup PITR o la frequenza di backup differenziale per i database attivi usando il portale di Azure:
- Passare al server logico di Azure che contiene i database di cui si vuole modificare il periodo di conservazione.
- Selezionare Backup nel riquadro a sinistra e quindi selezionare la scheda Criteri di conservazione.
- Selezionare i database per i quali si vuole modificare la conservazione dei backup PITR.
- Selezionare Configura criteri dalla barra delle azioni.
- Per modificare il periodo di conservazione per i backup di ripristino temporizzato, usare il dispositivo di scorrimento in Ripristino temporizzato.
- Per modificare la frequenza di backup differenziale, selezionare 12 ore o 24 ore dal menu a discesa in Frequenza di backup differenziale.
Preparare l'ambiente per l'interfaccia della riga di comando di Azure:
Modificare la conservazione dei backup PITR e la frequenza di backup differenziale per i database attivi usando l'esempio seguente:
# Set new PITR differential backup frequency on an active individual database
# Valid backup retention must be 1 to 35 days
# Valid differential backup frequency must be ether 12 or 24 hours
az sql db str-policy set \
--resource-group myresourcegroup \
--server myserver \
--name mydb \
--retention-days 28 \
--diffbackup-hours 24
Per modificare la conservazione dei backup PITR e la frequenza di backup differenziale per i database attivi, usare l'esempio di PowerShell seguente:
# Set a new PITR backup retention period on an active individual database
# Valid backup retention must be 1 to 35 days
Set-AzSqlDatabaseBackupShortTermRetentionPolicy -ResourceGroupName resourceGroup -ServerName testserver -DatabaseName testDatabase -RetentionDays 28
# Set a new PITR differential backup frequency on an active individual database
# Valid differential backup frequency must be ether 12 or 24 hours
Set-AzSqlDatabaseBackupShortTermRetentionPolicy -ResourceGroupName resourceGroup -ServerName testserver -DatabaseName testDatabase -RetentionDays 28 -DiffBackupIntervalInHours 24
Esempio di richiesta
PUT https://management.azure.com/subscriptions/00000000-1111-2222-3333-444444444444/resourceGroups/resourceGroup/providers/Microsoft.Sql/servers/testserver/databases/testDatabase/backupShortTermRetentionPolicies/default?api-version=2021-02-01-preview
Testo della richiesta
{
"properties":{
"retentionDays":28,
"diffBackupIntervalInHours":24
}
}
Risposta di esempio
{
"id": "/subscriptions/00000000-1111-2222-3333-444444444444/providers/Microsoft.Sql/resourceGroups/resourceGroup/servers/testserver/databases/testDatabase/backupShortTermRetentionPolicies/default",
"name": "default",
"type": "Microsoft.Sql/resourceGroups/servers/databases/backupShortTermRetentionPolicies",
"properties": {
"retentionDays": 28,
"diffBackupIntervalInHours":24
}
}
Per altre informazioni, vedere API REST per la conservazione dei backup.
È possibile configurare la ridondanza dell'archivio di backup per i database SQL di Azure quando si crea il database. È anche possibile modificare la ridondanza dell'archiviazione dopo la creazione del database.
Le modifiche alla ridondanza dell'archivio di backup apportate ai database esistenti si applicano solo ai Backup futuri. Il valore predefinito è archiviazione con ridondanza geografica. Per differenze nei prezzi tra l'archivio di backup con ridondanza locale, con ridondanza della zona e con ridondanza geografica, vedere la pagina dei prezzi di database SQL.
Nel portale di Azure è possibile scegliere un'opzione di ridondanza dell'archivio di backup quando si crea il database. In seguito, è possibile aggiornare la ridondanza dell'archivio di backup dalla pagina Calcolo e archiviazione delle impostazioni del database.
Quando si crea il database, scegliere l'opzione di ridondanza dell'archivio di backup nella scheda Dati principali.
Per database già esistenti, passare al database nel portale di Azure. Selezionare Calcolo e archiviazione nella sezione Impostazioni e quindi scegliere l'opzione desiderata per la ridondanza dell'archivio di backup.
Per configurare la ridondanza dell'archivio di backup quando si crea un nuovo database, è possibile specificare il parametro --backup-storage-redundancy
con il comando az sql db create
. I valori possibili sono Geo
, Zone
e Local
.
Per impostazione predefinita, tutti i database in database SQL di Azure usano l'archiviazione con ridondanza geografica per impostazione predefinita i backup. Il ripristino geografico è disabilitato se un database viene creato o aggiornato con un archivio di backup che abbia ridondanza locale o ridondanza della zona.
Questo esempio crea un database nel livello di servizio Utilizzo generico con ridondanza del backup locale:
az sql db create \
--resource-group myresourcegroup \
--server myserver \
--name mydb \
--tier GeneralPurpose \
--backup-storage-redundancy Local
Ad eccezione dei database Hyperscale e Basic, è possibile aggiornare l'impostazione di ridondanza dell'archivio di backup per un database esistente usando il parametro --backup-storage-redundancy
e il comando az sql db update
. Potrebbero essere necessarie fino a 48 ore prima che le modifiche vengano applicate al database. Il passaggio dall'archivio di backup con ridondanza geografica all'archiviazione con ridondanza locale o con ridondanza della zona disabilita il ripristino geografico.
Questo codice di esempio modifica la ridondanza dell'archivio di backup in Local
:
az sql db update \
--resource-group myresourcegroup \
--server myserver \
--name mydb \
--backup-storage-redundancy Local
Hyperscale
Valutare attentamente l'opzione di configurazione per --backup-storage-redundancy
quando si crea un database Hyperscale. Per i database Hyperscale, la ridondanza dell'archiviazione può essere specificata solo durante il processo di creazione del database. Non sarà possibile aggiornarla in un secondo momento. L'opzione di ridondanza di archiviazione selezionata verrà usata per la durata del database sia per la ridondanza di archiviazione dei dati sia per la ridondanza dell'archivio di backup. Per altre informazioni, vedere Ridondanza dell'archivio di backup Hyperscale.
I database Hyperscale esistenti possono eseguire la migrazione a una ridondanza di archiviazione diversa tramite la replica geografica attiva, che comporta solo tempi di inattività minimi. In alternativa, è possibile eseguire la migrazione a una ridondanza di archiviazione diversa usando la copia del database o il ripristino temporizzato. Questo esempio crea un database nel livello di servizio Hyperscale con ridondanza della zona:
az sql db create \
--resource-group myresourcegroup \
--server myserver \
--name mydb \
--tier Hyperscale \
--backup-storage-redundancy Zone
Per altre informazioni, vedere az sql db create e az sql db update.
Non è possibile aggiornare direttamente la ridondanza dell'archivio di backup di un database Hyperscale. Tuttavia, è possibile modificarla usando il comando di copia del database con il parametro --backup-storage-redundancy
. Questo esempio copia un database Hyperscale in un nuovo database che usa hardware Gen5 e due vCore. Il nuovo database ha la ridondanza del backup impostata su Zone
.
az sql db copy \
--resource-group myresourcegroup \
--server myserver
--name myHSdb
--dest-resource-group mydestresourcegroup
--dest-server destdb
--dest-name myHSdb
--service-objective HS_Gen5_2
--read-replicas 0
--backup-storage-redundancy Zone
Per informazioni dettagliate sulla sintassi, vedere az sql db copy. Per informazioni generali sulla copia del database, vedere Copiare coerentemente e in modo transazionale una copia di un database in database SQL di Azure.
Per configurare la ridondanza dell'archivio di backup quando si crea un nuovo database, è possibile specificare il parametro -BackupStorageRedundancy
con il cmdlet New-AzSqlDatabase
. I valori possibili sono Geo
, Zone
e Local
. Per impostazione predefinita, tutti i database in database SQL di Azure usano l'archiviazione con ridondanza geografica per impostazione predefinita i backup. Il ripristino geografico è disabilitato se viene creato un database con archivio di backup con ridondanza locale o con ridondanza della zona.
Questo esempio crea un database nel livello di servizio Utilizzo generico con ridondanza del backup locale:
# Create a new database with geo-redundant backup storage.
New-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database03" -Edition "GeneralPurpose" -Vcore 2 -ComputeGeneration "Gen5" -BackupStorageRedundancy Local
Ad eccezione dei database Hyperscale e Basic, è possibile usare il parametro -BackupStorageRedundancy
con il cmdlet Set-AzSqlDatabase
per aggiornare l'impostazione di ridondanza dell'archivio di backup per un database esistente. I valori possibili sono Geo
, Zone
e Local
. Potrebbero essere necessarie fino a 48 ore prima che le modifiche vengano applicate al database. Il passaggio dall'archivio di backup con ridondanza geografica all'archiviazione con ridondanza locale o con ridondanza della zona disabilita il ripristino geografico.
Questo codice di esempio modifica la ridondanza dell'archivio di backup in Local
:
# Change the backup storage redundancy for Database01 to zone-redundant.
Set-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -DatabaseName "Database01" -ServerName "Server01" -BackupStorageRedundancy Local
Per informazioni dettagliate, vedere Set-AzSqlDatabase.
Hyperscale
Valutare attentamente l'opzione di configurazione per --backup-storage-redundancy
quando si crea un database Hyperscale. Per i database Hyperscale, è possibile specificare la ridondanza dell'archiviazione solo durante il processo di creazione del database. L'opzione di ridondanza di archiviazione selezionata verrà usata per la durata del database sia per la ridondanza di archiviazione dei dati sia per la ridondanza dell'archivio di backup. Per altre informazioni, vedere Backup hyperscale e ridondanza di archiviazione.
I database esistenti possono eseguire la migrazione a una ridondanza di archiviazione diversa tramite la copia del database o il ripristino temporizzato. Questo esempio crea un database nel livello di servizio Hyperscale con ridondanza della zona:
# Create a new database with geo-redundant backup storage.
New-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database03" -Edition "Hyperscale" -Vcore 2 -ComputeGeneration "Gen5" -BackupStorageRedundancy Zone
Per informazioni dettagliate sulla sintassi, vedere New-AzSqlDatabase.
Non è possibile aggiornare la ridondanza dell'archivio di backup di un database Hyperscale esistente. Tuttavia, è possibile usare il comando copia database per creare una copia del database. È quindi possibile usare il parametro -BackupStorageRedundancy
per aggiornare la ridondanza dell'archivio di backup.
Questo esempio copia un database Hyperscale in un nuovo database usando l'hardware Gen5 e due vCore. Il nuovo database ha la ridondanza del backup impostata su Zone
.
# Change the backup storage redundancy for Database01 to zone-redundant.
New-AzSqlDatabaseCopy -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "HSSourceDB" -CopyResourceGroupName "DestResourceGroup" -CopyServerName "DestServer" -CopyDatabaseName "HSDestDB" -Vcore 2 -ComputeGeneration "Gen5" -ComputeModel Provisioned -BackupStorageRedundancy Zone
Per informazioni dettagliate sulla sintassi, vedere New-AzSqlDatabaseCopy. Per informazioni generali sulla copia del database, vedere Copiare coerentemente e in modo transazionale una copia di un database in database SQL di Azure.
Nota
Per usare il parametro -BackupStorageRedundancy
con il ripristino del database, la copia del database o creare operazioni secondarie, usare Azure PowerShell versione Az.Sql 2.11.0 o successiva.
Non è attualmente possibile modificare la ridondanza dell'archivio di backup usando l'API REST.