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 ziet u hoe u de pitrretentie 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 meer nodig zijn om PITR te bieden binnen de nieuwe bewaarperiode, 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 deze mogelijkheid na verloop van tijd omdat het systeem back-ups voor langere perioden zal 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 back-upretentie van pitr wilt wijzigen.
- Selecteer Beleid configureren 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 .
De omgeving voorbereiden op de Azure CLI:
Wijzig de back-upretentie en differentiële back-upfrequentie voor actieve databases met behulp 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 back-upretentie en differentiële back-upfrequentie 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
Aanvraagtekst
{
"properties":{
"retentionDays":28,
"diffBackupIntervalInHours":24
}
}
Voorbeeldrespons
{
"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-upretentie voor 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. Zie de prijzenpagina van SQL Database voor verschillen in prijzen tussen lokaal redundante, zone-redundante en geografisch redundante back-upopslag.
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 pagina Compute & Storage van uw database-instellingen.
Wanneer u uw database maakt, kiest u de optie back-upopslagredundantie op het tabblad Basisinformatie .
Voor bestaande databases gaat u naar uw database in Azure Portal. Selecteer Compute & storage onder Instellingen en kies vervolgens de gewenste optie voor back-upopslagredundantie.
Als u redundantie van back-upopslag wilt configureren wanneer u een nieuwe database maakt, kunt u de --backup-storage-redundancy parameter opgeven met de az sql db create opdracht. 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 of bijgewerkt met lokaal redundante of zone-redundante back-upopslag.
In dit voorbeeld wordt een database gemaakt in de servicelaag Algemeen gebruik 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 --backup-storage-redundancy parameter en de az sql db update opdracht. 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 geo-herstel uitgeschakeld.
In deze voorbeeldcode wordt de redundantie van de 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 over redundantie van Hyperscale-back-upopslag.
Bestaande Hyperscale-databases kunnen worden gemigreerd naar verschillende opslagredundantie via actieve geo-replicatie, wat minimale downtime veroorzaakt. U kunt ook migreren naar een andere opslagredundantie met behulp van databasekopie of herstel naar een bepaald 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 update voor 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 voor het kopiëren van de database met de --backup-storage-redundancy parameter. 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
Zie az sql db copy voor syntaxisdetails. Zie Een transactioneel consistente kopie van een database in Azure SQL Database kopiëren voor een overzicht van databasekopie.
Als u redundantie van back-upopslag wilt configureren wanneer u een nieuwe database maakt, kunt u de -BackupStorageRedundancy parameter 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-upopslag.
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 -BackupStorageRedundancy parameter met de Set-AzSqlDatabase cmdlet gebruiken om de instelling voor redundantie van 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 geo-herstel uitgeschakeld.
In deze voorbeeldcode wordt de redundantie van de 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-AzSqlDatabase voor 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 over Hyperscale-back-ups en opslagredundantie.
Bestaande databases kunnen worden gemigreerd naar verschillende opslagredundantie via databasekopie of herstel 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-AzSqlDatabase voor meer informatie over de syntaxis.
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 -BackupStorageRedundancy parameter gebruiken om de redundantie van de 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-upredundantie 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-AzSqlDatabaseCopy voor syntaxisdetails. Zie Een transactioneel consistente kopie van een database in Azure SQL Database kopiëren voor een overzicht van databasekopie.
Notitie
Als u de -BackupStorageRedundancy parameter wilt gebruiken 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