Sie können die Standardaufbewahrungszeit für Sicherungen der Zeitpunktwiederherstellung (PITR) und die Häufigkeit der differenziellen Sicherungen über das Azure-Portal, die Azure CLI, PowerShell oder die REST-API ändern. Die folgenden Beispiele veranschaulichen, wie Sie die PITR-Aufbewahrung auf 28 Tage und die differenziellen Sicherungen auf ein Intervall von 24 Stunden ändern.
Warnung
Wenn Sie die aktuelle Beibehaltungsdauer verringern, verlieren Sie die Möglichkeit, Zeitpunkte wiederherzustellen, die älter als die neue Beibehaltungsdauer sind. Sicherungen, die für die Bereitstellung von Point-in-Time-Wiederherstellungen innerhalb der neuen Beibehaltungsdauer nicht mehr benötigt werden, werden gelöscht.
Wenn Sie die aktuelle Beibehaltungsdauer verringern, wird die Möglichkeit, Zeitpunkte innerhalb der neuen Beibehaltungsdauer wiederherzustellen, nicht sofort hergestellt. Sie erhalten diese Möglichkeit im Lauf der Zeit, während das System beginnt, Sicherungen über längere Zeiträume aufzubewahren.
So ändern Sie den Aufbewahrungszeitraum für die PITR-Sicherung oder die Häufigkeit der differenziellen Sicherung für aktive Datenbanken über das Azure-Portal:
- Wechseln Sie zum logischen Server in Azure mit den Datenbanken, deren Aufbewahrungszeitraum Sie ändern möchten.
- Wählen Sie im linken Bereich Sicherungen und dann die Registerkarte Aufbewahrungsrichtlinien aus.
- Wählen Sie die Datenbanken aus, für die Sie die PITR-Sicherungsaufbewahrung ändern möchten.
- Wählen Sie in der Aktionsleiste die Option Richtlinien konfigurieren aus.
- Um den Aufbewahrungszeitraum für Sicherungen mit Zeitpunktwiederherstellung zu ändern, verwenden Sie den Schieberegler unter Zeitpunktwiederherstellung.
- Um die differenzielle Sicherungshäufigkeit zu ändern, wählen Sie 12 Stunden oder 24 Stunden aus dem Dropdownmenü unter Differenzielle Sicherungshäufigkeit aus.
Vorbereiten der Umgebung für die Azure CLI:
Verwenden Sie die Bash-Umgebung in Azure Cloud Shell. Weitere Informationen finden Sie unter Schnellstart für Bash in Azure Cloud Shell.
Wenn Sie CLI-Referenzbefehle lieber lokal ausführen, installieren Sie die Azure CLI. Wenn Sie Windows oder macOS ausführen, sollten Sie die Azure CLI in einem Docker-Container ausführen. Weitere Informationen finden Sie unter Ausführen der Azure CLI in einem Docker-Container.
Wenn Sie eine lokale Installation verwenden, melden Sie sich mithilfe des Befehls az login bei der Azure CLI an. Führen Sie die in Ihrem Terminal angezeigten Schritte aus, um den Authentifizierungsprozess abzuschließen. Informationen zu anderen Anmeldeoptionen finden Sie unter Anmelden mit der Azure CLI.
Installieren Sie die Azure CLI-Erweiterung beim ersten Einsatz, wenn Sie dazu aufgefordert werden. Weitere Informationen zu Erweiterungen finden Sie unter Verwenden von Erweiterungen mit der Azure CLI.
Führen Sie az version aus, um die installierte Version und die abhängigen Bibliotheken zu ermitteln. Führen Sie az upgrade aus, um das Upgrade auf die aktuelle Version durchzuführen.
Ändern Sie die PITR-Sicherungsaufbewahrung und die Häufigkeit der differenziellen Sicherung für aktive Datenbanken mit Hilfe des folgenden Beispiels:
# 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
Verwenden Sie das folgende PowerShell-Beispiel, um die PITR-Sicherungsaufbewahrung und die Häufigkeit der differenziellen Sicherung für aktive Datenbanken zu ändern:
# 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
Beispiel für eine Anforderung
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
Anforderungstext
{
"properties":{
"retentionDays":28,
"diffBackupIntervalInHours":24
}
}
Beispiel für eine Antwort
{
"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
}
}
Weitere Informationen finden Sie unter REST-API für die Aufbewahrung von Sicherungen.
Sie können Sicherungsspeicherredundanz für Datenbanken in Azure SQL-Datenbank bei der Erstellung Ihrer Datenbank konfigurieren. Sie können die Speicherredundanz auch ändern, nachdem die Datenbank bereits erstellt wurde.
Änderungen der Sicherungsspeicherredundanz, die an vorhandenen Datenbanken vorgenommen werden, gelten nur für zukünftige Sicherungen. Standardmäßig wird georedundanter Speicher verwendet. Informationen zu den Preisunterschieden zwischen lokal redundantem, zonenredundantem und georedundantem Sicherungsspeicher finden Sie auf der Seite mit der Preisübersicht für SQL-Datenbank.
Im Azure-Portal können Sie beim Erstellen Ihrer Datenbank eine Option zur Sicherungsspeicherredundanz auswählen. Sie können die Sicherungsspeicherredundanz später über die Seite Compute und Speicher Ihrer Datenbankeinstellungen aktualisieren.
Wenn Sie Ihre Datenbank erstellen, wählen Sie auf der Registerkarte Grundlagen die Option „Redundanz für Sicherungsspeicher“ aus.
Wechseln Sie für vorhandene Datenbanken im Azure-Portal zu Ihrer Datenbank. Wählen Sie unter Einstellungen die Option Compute und Speicher und dann Ihre gewünschte Option für die Sicherungsspeicherredundanz aus.
Zum Konfigurieren der Sicherungsspeicherredundanz beim Erstellen einer neuen Datenbank können Sie den Parameter --backup-storage-redundancy mit dem Befehl az sql db create angeben. Mögliche Werte sind Geo, Zone und Local.
Standardmäßig verwenden alle Datenbanken in Azure SQL-Datenbank georedundanten Speicher für Sicherungen. Die Geowiederherstellung ist deaktiviert, wenn eine Datenbank mit lokal redundantem oder zonenredundanten Sicherungsspeicher erstellt oder aktualisiert wird.
In diesem Beispiel wird eine Datenbank der Dienstebene Universell mit lokaler Sicherungsredundanz erstellt:
az sql db create \
--resource-group myresourcegroup \
--server myserver \
--name mydb \
--tier GeneralPurpose \
--backup-storage-redundancy Local
Mit Ausnahme von Hyperscale- und Basic-Datenbanken können Sie die Einstellung der Sicherungsspeicherredundanz für eine vorhandene Datenbank mit dem Parameter --backup-storage-redundancy und dem Befehl az sql db update aktualisieren. Es kann bis zu 48 Stunden dauern, bis die Änderungen auf die Datenbank angewendet werden. Durch den Wechsel von georedundantem Sicherungsspeicher zu lokal redundantem oder zonenredundantem Sicherungsspeicher wird die Geowiederherstellung deaktiviert.
Dieser Beispielcode ändert die Sicherungsspeicherredundanz in Local:
az sql db update \
--resource-group myresourcegroup \
--server myserver \
--name mydb \
--backup-storage-redundancy Local
Hyperscale
Wählen Sie die Konfigurationsoption für --backup-storage-redundancy sorgfältig aus, wenn Sie eine Hyperscale-Datenbank erstellen. Die Speicherredundanz kann nur während der Erstellung einer Hyperscale-Datenbank angegeben werden. Sie können sie später nicht mehr ändern. Die ausgewählte Speicherredundanzoption wird während der gesamten Lebensdauer der Datenbank sowohl für die Datenspeicherredundanz als auch für die Sicherungsspeicherredundanz verwendet. Weitere Informationen finden Sie unter Hyperscale-Sicherungsspeicherredundanz.
Vorhandene Hyperscale-Datenbanken können über aktive Georeplikation zu unterschiedlichen Speicherredundanzen migrieren, was zu minimalen Ausfallzeiten führt. Alternativ können Sie mithilfe einer Datenbankkopie oder einer Zeitpunktwiederherstellung zu einer anderen Speicherredundanz migrieren. In diesem Beispiel wird eine Datenbank auf der Dienstebene „Hyperscale“ mit Zonenredundanz erstellt:
az sql db create \
--resource-group myresourcegroup \
--server myserver \
--name mydb \
--tier Hyperscale \
--backup-storage-redundancy Zone
Weitere Informationen finden Sie unter az sql db create und az sql db update.
Sie können die Sicherungsspeicherredundanz einer Hyperscale-Datenbank nicht direkt aktualisieren. Sie können die Einstellung jedoch ändern, indem Sie den Befehl zum Kopieren der Datenbank mit dem Parameter --backup-storage-redundancy verwenden. In diesem Beispiel wird eine Hyperscale-Datenbank in eine neue Datenbank kopiert, die Gen5-Hardware und zwei virtuelle Kerne verwendet. Für die neue Datenbank ist die Sicherungsredundanz auf Zone festgelegt.
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
Details zur Syntax finden Sie unter az sql db copy. Eine Übersicht über das Kopieren von Datenbanken finden Sie unter Kopieren einer transaktionskonsistenten Kopie einer Datenbank in Azure SQL-Datenbank.
Zum Konfigurieren der Sicherungsspeicherredundanz beim Erstellen einer neuen Datenbank können Sie den Parameter -BackupStorageRedundancy mit dem Cmdlet New-AzSqlDatabase angeben. Mögliche Werte sind Geo, Zone und Local. Standardmäßig verwenden alle Datenbanken in Azure SQL-Datenbank georedundanten Speicher für Sicherungen. Die Geowiederherstellung ist deaktiviert, wenn eine Datenbank mit lokal redundantem oder zonenredundanten Sicherungsspeicher erstellt wird.
In diesem Beispiel wird eine Datenbank der Dienstebene Universell mit lokaler Sicherungsredundanz erstellt:
# 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
Mit Ausnahme von Hyperscale- und Basic-Datenbanken können Sie den Parameter -BackupStorageRedundancy mit dem Cmdlet Set-AzSqlDatabase verwenden, um die Einstellung für die Sicherungsspeicherredundanz für eine vorhandene Datenbank zu aktualisieren. Mögliche Werte sind Geo, Zone und Local. Es kann bis zu 48 Stunden dauern, bis die Änderungen auf die Datenbank angewendet werden. Durch den Wechsel von georedundantem Sicherungsspeicher zu lokal redundantem oder zonenredundantem Sicherungsspeicher wird die Geowiederherstellung deaktiviert.
Dieser Beispielcode ändert die Sicherungsspeicherredundanz in Local:
# Change the backup storage redundancy for Database01 to zone-redundant.
Set-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -DatabaseName "Database01" -ServerName "Server01" -BackupStorageRedundancy Local
Details hierzu finden Sie unter Set-AzSqlDatabase.
Hyperscale
Wählen Sie die Konfigurationsoption für --backup-storage-redundancy sorgfältig aus, wenn Sie eine Hyperscale-Datenbank erstellen. Sie können die Speicherredundanz nur während der Erstellung von Hyperscale-Datenbanken angeben. Die ausgewählte Speicherredundanzoption wird während der gesamten Lebensdauer der Datenbank sowohl für die Datenspeicherredundanz als auch für die Sicherungsspeicherredundanz verwendet. Weitere Informationen finden Sie unter Hyperscale-Sicherungen und Speicherredundanz.
Vorhandene Datenbanken können mithilfe einer Datenbankkopie oder einer Zeitpunktwiederherstellung zu einer anderen Speicherredundanz migriert werden. In diesem Beispiel wird eine Datenbank auf der Dienstebene Hyperscale mit Zonenredundanz erstellt:
# 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
Details zur Syntax finden Sie unter New-AzSqlDatabase.
Die Sicherungsspeicherredundanz einer vorhandenen Hyperscale-Datenbank kann nicht aktualisiert werden. Sie können jedoch den Befehl zum Kopieren der Datenbank verwenden, um eine Kopie der Datenbank zu erstellen. Anschließend können Sie den Parameter -BackupStorageRedundancy verwenden, um die Sicherungsspeicherredundanz zu aktualisieren.
In diesem Beispiel wird eine Hyperscale-Datenbank in eine neue Datenbank mit Verwendung von Gen5-Hardware und zwei virtuellen Kernen kopiert. Für die neue Datenbank ist die Sicherungsredundanz auf Zone festgelegt.
# 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
Details zur Syntax finden Sie unter New-AzSqlDatabaseCopy. Eine Übersicht über das Kopieren von Datenbanken finden Sie unter Kopieren einer transaktionskonsistenten Kopie einer Datenbank in Azure SQL-Datenbank.
Hinweis
Zur Verwendung des Parameters -BackupStorageRedundancy mit Datenwiederherstellung, Datenbankkopien oder Vorgängen zur Erstellung sekundärer Replikate verwenden Sie die Azure PowerShell-Version Az.Sql 2.11.0 oder höher.
Es ist derzeit nicht möglich, die Sicherungsspeicherredundanz mithilfe der REST-API zu ändern.
Azure SQL-Datenbank