U kunt de standaardretentieperiode voor herstel naar een bepaald tijdstip en de frequentie voor differentiële back-ups wijzigen met behulp van Azure Portal, de Azure CLI, PowerShell of de REST API. In de volgende voorbeelden wordt getoond hoe u de PITR-retentie wijzigt in 28 dagen en de differentiële back-ups in een interval van 24 uur.
Waarschuwing
Als u de huidige bewaarperiode vermindert, verliest u de mogelijkheid om te herstellen naar punten die ouder zijn dan de nieuwe bewaarperiode. Back-ups die niet langer nodig zijn om pitr binnen de nieuwe bewaarperiode te leveren, worden verwijderd.
Als u de huidige bewaarperiode verhoogt, krijgt u niet onmiddellijk de mogelijkheid om te herstellen naar oudere tijdstippen binnen de nieuwe bewaarperiode. U krijgt die mogelijkheid in de loop van de tijd, omdat het systeem back-ups voor langere perioden begint te bewaren.
Als u de bewaarperiode van de pitr-back-up of de differentiële back-upfrequentie voor actieve databases wilt wijzigen met behulp van Azure Portal:
- Ga naar de logische server in Azure met de databases waarvan u de bewaarperiode wilt wijzigen.
- Selecteer back-ups in het linkerdeelvenster en selecteer vervolgens het tabblad Bewaarbeleid.
- Selecteer de databases waarvoor u de retentie van PITR-back-ups wilt wijzigen.
- Selecteer Configureer beleidsregels op de actiebalk.
- Als u de bewaarperiode voor herstel naar een bepaald tijdstip wilt wijzigen, gebruikt u de schuifregelaar onder Herstel naar een bepaald tijdstip.
- Als u de frequentie van differentiële back-ups wilt wijzigen, selecteert u 12 uur of 24 uur in de vervolgkeuzelijst onder Differentiële back-upfrequentie.
Bereid uw omgeving voor op de Azure CLI:
Wijzig de PITR back-upretentie en de frequentie van differentiële back-ups voor actieve databases door gebruik te maken van het volgende voorbeeld:
# 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
Gebruik het volgende PowerShell-voorbeeld om de PITR-back-upretentie en de frequentie van differentiële back-ups voor actieve databases te wijzigen.
# 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
Voorbeeldaanvraag
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
Aanvraaginhoud
{
"properties":{
"retentionDays":28,
"diffBackupIntervalInHours":24
}
}
Voorbeeldantwoord
{
"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
}
}
Zie REST API voor back-upretentievoor meer informatie.
U kunt redundantie voor back-upopslag configureren voor databases in Azure SQL Database wanneer u uw database maakt. U kunt ook de opslagredundantie wijzigen nadat de database al is gemaakt.
Redundantiewijzigingen voor back-upopslag die zijn aangebracht in bestaande databases, zijn alleen van toepassing op toekomstige back-ups. De standaardwaarde is geografisch redundante opslag. Voor verschillen in prijzen tussen lokaal redundante, zone-redundante en geografisch redundante back-upopslag, raadpleegt u de pagina met prijzen van SQL Database.
In Azure Portal kunt u een redundantieoptie voor back-upopslag kiezen wanneer u uw database maakt. U kunt de redundantie van de back-upopslag later bijwerken vanaf de Compute &-opslag pagina van uw database-instellingen.
Wanneer u uw database maakt, kiest u de redundantie-optie voor back-upopslag op het tabblad Basis.
Ga voor bestaande databases naar uw database in de Azure Portal. Selecteer Compute &-opslag onder Instellingenen kies vervolgens de gewenste optie voor redundantie van back-upopslag.
Als u redundantie van back-upopslag wilt configureren wanneer u een nieuwe database maakt, kunt u de parameter --backup-storage-redundancy opgeven met de opdracht az sql db create. Mogelijke waarden zijn Geo, Zoneen Local.
Standaard gebruiken alle databases in Azure SQL Database geografisch redundante opslag voor back-ups. Geo-herstel is uitgeschakeld wanneer een database wordt aangemaakt of bijgewerkt met lokaal redundante of zone-redundante back-upopslag.
In dit voorbeeld wordt er een database gemaakt in de servicelaag Algemene Doeleinden met lokale back-upredundantie.
az sql db create \
--resource-group myresourcegroup \
--server myserver \
--name mydb \
--tier GeneralPurpose \
--backup-storage-redundancy Local
Met uitzondering van Hyperscale- en Basic-databases kunt u de instelling voor redundantie van back-upopslag voor een bestaande database bijwerken met behulp van de parameter --backup-storage-redundancy en de opdracht az sql db update. Het kan tot 48 uur duren voordat de wijzigingen in de database zijn toegepast. Als u overschakelt van geografisch redundante back-upopslag naar lokaal redundante of zone-redundante opslag, wordt de geo-hersteloptie uitgeschakeld.
In deze voorbeeldcode wordt de redundantie van back-upopslag gewijzigd in Local:
az sql db update \
--resource-group myresourcegroup \
--server myserver \
--name mydb \
--backup-storage-redundancy Local
Hyperscale
Houd zorgvuldig rekening met de configuratieoptie voor --backup-storage-redundancy wanneer u een Hyperscale-database maakt. De opslagredundantie kan alleen worden opgegeven tijdens het maken van de database voor Hyperscale-databases. U kunt deze later niet bijwerken. De geselecteerde optie voor opslagredundantie wordt gebruikt voor de levensduur van de database voor zowel redundantie van gegevensopslag als back-upopslagredundantie. Meer informatie vindt u in Redundantie van Hyperscale-back-upopslag.
Bestaande Hyperscale-databases kunnen worden gemigreerd naar verschillende opslagredundantie via actieve geo-replicatie, wat resulteert in minimale downtime. U kunt ook migreren naar een andere opslagredundantie door gebruik te maken van databasekopie of herstel naar een specifiek tijdstip. In dit voorbeeld wordt een database gemaakt in de Hyperscale-servicelaag met zoneredundantie:
az sql db create \
--resource-group myresourcegroup \
--server myserver \
--name mydb \
--tier Hyperscale \
--backup-storage-redundancy Zone
Zie az sql db create en az sql db updatevoor meer informatie.
U kunt de redundantie van back-upopslag van een Hyperscale-database niet rechtstreeks bijwerken. U kunt deze echter wijzigen met behulp van de opdracht databasekopie met de parameter --backup-storage-redundancy. In dit voorbeeld wordt een Hyperscale-database gekopieerd naar een nieuwe database die gebruikmaakt van Gen5-hardware en twee vCores. De nieuwe database heeft de back-upredundantie ingesteld op 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
Voor syntaxisdetails, zie az sql db copy. Zie Een transactioneel consistente kopie van een database kopiëren in Azure SQL Databasevoor een overzicht van databasekopie.
Als u redundantie van back-upopslag wilt configureren wanneer u een nieuwe database maakt, kunt u de parameter -BackupStorageRedundancy opgeven met de New-AzSqlDatabase-cmdlet. Mogelijke waarden zijn Geo, Zoneen Local. Standaard gebruiken alle databases in Azure SQL Database geografisch redundante opslag voor back-ups. Geo-herstel is uitgeschakeld als een database wordt gemaakt met lokaal redundante of zone-redundante back-up-opslag.
In dit voorbeeld wordt een database gemaakt in de servicelaag Algemeen gebruik met lokale back-upredundantie:
# 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
Met uitzondering van Hyperscale- en Basic-databases kunt u de parameter -BackupStorageRedundancy met de Set-AzSqlDatabase-cmdlet gebruiken om de redundantie-instelling voor back-upopslag voor een bestaande database bij te werken. Mogelijke waarden zijn Geo, Zoneen Local. Het kan tot 48 uur duren voordat de wijzigingen in de database zijn toegepast. Als u overschakelt van geografisch redundante back-upopslag naar lokaal redundante of zone-redundante opslag, wordt geografisch herstel uitgeschakeld.
In deze voorbeeldcode wordt de redundantie van back-upopslag gewijzigd in Local:
# Change the backup storage redundancy for Database01 to zone-redundant.
Set-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -DatabaseName "Database01" -ServerName "Server01" -BackupStorageRedundancy Local
Zie Set-AzSqlDatabasevoor meer informatie.
Hyperscale
Houd zorgvuldig rekening met de configuratieoptie voor --backup-storage-redundancy wanneer u een Hyperscale-database maakt. U kunt opslagredundantie alleen opgeven tijdens het maken van de database voor Hyperscale-databases. De geselecteerde optie voor opslagredundantie wordt gebruikt voor de levensduur van de database voor zowel redundantie van gegevensopslag als back-upopslagredundantie. Meer informatie vindt u in Hyperscale-back-ups en opslagredundantie.
Bestaande databases kunnen migreren naar diverse opslagredundantiemogelijkheden via databasekopie of terugzetten naar een bepaald tijdstip. In dit voorbeeld wordt een database gemaakt in de Hyperscale servicelaag met zoneredundantie:
# 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
Zie New-AzSqlDatabasevoor syntaxisdetails.
Back-upopslagredundantie van een bestaande Hyperscale-database kan niet worden bijgewerkt. U kunt echter de opdracht databasekopie gebruiken om een kopie van de database te maken. Vervolgens kunt u de parameter -BackupStorageRedundancy gebruiken om de redundantie van back-upopslag bij te werken.
In dit voorbeeld wordt een Hyperscale-database gekopieerd naar een nieuwe database met behulp van Gen5-hardware en twee vCores. De nieuwe database heeft de back-up-redundantie ingesteld op 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
Zie New-AzSqlDatabaseCopyvoor syntaxisdetails. Zie Een transactioneel consistente kopie van een database kopiëren in Azure SQL Databasevoor een overzicht van databasekopie.
Notitie
Als u de parameter -BackupStorageRedundancy met databaseherstel, databasekopie of secundaire bewerkingen wilt maken, gebruikt u Azure PowerShell-versie Az.Sql 2.11.0 of hoger.
Het is momenteel niet mogelijk om redundantie van back-upopslag te wijzigen met behulp van de REST API.
Azure SQL Database-