[!INCLUDEappliesto-sqldb]

[!div class="op_single_selector"]

• Azure SQL Database
• Azure SQL Managed Instance

This article provides examples to modify automated backup settings for Azure SQL Database, such as the short-term retention policy and the backup storage redundancy option that's used for backups. For Azure SQL Managed Instance, see Change automated backup settings for Azure SQL Managed Instance.

[!INCLUDE GDPR-related guidance]

You can change the default point-in-time recovery (PITR) backup retention period and the differential backup frequency by using the Azure portal, the Azure CLI, PowerShell, or the REST API. The following examples illustrate how to change the PITR retention to 28 days and the differential backups to a 24-hour interval.

To change the PITR backup retention period or the differential backup frequency for active databases by using the Azure portal:

1. Go to the logical server in Azure with the databases whose retention period you want to change.
2. Select Backups on the left pane, and then select the Retention policies tab.
3. Select the databases for which you want to change the PITR backup retention.
4. Select Configure policies from the action bar.
5. To change the retention period for point-in-time restore backups, use the slider under Point-in-time restore.
6. To change differential backup frequency, select 12 Hours or 24 hours from the drop-down menu under Differential backup frequency .

:::image type="content" source="./media/automated-backups-overview/configure-backup-retention-sqldb.png" alt-text="Screenshot of the Azure portal, where you can change the PITR retention settings at the server level. ":::

Prepare your environment for the Azure CLI:

[!INCLUDEazure-cli-prepare-your-environment-no-header]

Change the PITR backup retention and differential backup frequency for active databases by using the following example:

# 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

To change the PITR backup retention and differential backup frequency for active databases, use the following PowerShell example:

# 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

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

{ 
    "properties":{
        "retentionDays":28,
        "diffBackupIntervalInHours":24
  }
}

{ 
  "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
  }
}

For more information, see Backup retention REST API.

You can configure backup storage redundancy for databases in Azure SQL Database when you create your database. You can also change the storage redundancy after the database is already created.

Backup storage redundancy changes made to existing databases apply to future backups only. The default value is geo-redundant storage. For differences in pricing between locally redundant, zone-redundant, and geo-redundant backup storage, see the SQL Database pricing page.

Storage redundancy for Hyperscale databases is unique. To learn more, review Hyperscale backup storage redundancy.

In the Azure portal, you can choose a backup storage redundancy option when you create your database. You can later update the backup storage redundancy from the Compute & storage page of your database settings.

When you're creating your database, choose the backup storage redundancy option on the Basics tab.

:::image type="content" source="./media/automated-backups-overview/sql-database-backup-storage-redundancy.png" alt-text="Screenshot of the Azure portal, where you can change backup storage redundancy from the Basics tab when you create your database.":::

For existing databases, go to your database in the Azure portal. Select Compute & storage under Settings, and then choose your desired option for backup storage redundancy.

:::image type="content" source="./media/automated-backups-overview/change-redundancy-for-existing-databases.png" alt-text="Screenshot of the Azure portal that shows where to change the backup storage redundancy for existing databases.":::

To configure backup storage redundancy when you're creating a new database, you can specify the --backup-storage-redundancy parameter with the az sql db create command. Possible values are Geo, Zone, and Local.

By default, all databases in Azure SQL Database use geo-redundant storage for backups. Geo-restore is disabled if a database is created or updated with locally redundant or zone-redundant backup storage.

This example creates a database in the General Purpose service tier with local backup redundancy:

az sql db create \
    --resource-group myresourcegroup \
    --server myserver \
    --name mydb \
    --tier GeneralPurpose \
    --backup-storage-redundancy Local

Except for Hyperscale and Basic databases, you can update the backup storage redundancy setting for an existing database by using the --backup-storage-redundancy parameter and the az sql db update command. It might take up to 48 hours for the changes to be applied on the database. Switching from geo-redundant backup storage to locally redundant or zone-redundant storage disables geo-restore.

This example code changes the backup storage redundancy to Local:

az sql db update \
    --resource-group myresourcegroup \
    --server myserver \
    --name mydb \
    --backup-storage-redundancy Local

Carefully consider the configuration option for --backup-storage-redundancy when you're creating a Hyperscale database. The storage redundancy can be specified only during the database creation process for Hyperscale databases. You can't update it later. The selected storage redundancy option will be used for the lifetime of the database for both data storage redundancy and backup storage redundancy. Learn more in Hyperscale backup storage redundancy.

Existing Hyperscale databases can migrate to different storage redundancy through active geo-replication, which causes minimal downtime. Alternatively, you can migrate to a different storage redundancy by using database copy or point-in-time restore. This example creates a database in the Hyperscale service tier with zone redundancy:

az sql db create \
    --resource-group myresourcegroup \
    --server myserver \
    --name mydb \
    --tier Hyperscale \
    --backup-storage-redundancy Zone

For more information, see az sql db create and az sql db update.

You can't update the backup storage redundancy of a Hyperscale database directly. However, you can change it by using the database copy command with the --backup-storage-redundancy parameter. This example copies a Hyperscale database to a new database that uses Gen5 hardware and two vCores. The new database has the backup redundancy set to 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

For syntax details, see az sql db copy. For an overview of database copy, see Copy a transactionally consistent copy of a database in Azure SQL Database.

To configure backup storage redundancy when you're creating a new database, you can specify the -BackupStorageRedundancy parameter with the New-AzSqlDatabase cmdlet. Possible values are Geo, Zone, and Local. By default, all databases in Azure SQL Database use geo-redundant storage for backups. Geo-restore is disabled if a database is created with locally redundant or zone-redundant backup storage.

This example creates a database in the General Purpose service tier with local backup redundancy:

# 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

Except for Hyperscale and Basic databases, you can use the -BackupStorageRedundancy parameter with the Set-AzSqlDatabase cmdlet to update the backup storage redundancy setting for an existing database. Possible values are Geo, Zone, and Local. It might take up to 48 hours for the changes to be applied on the database. Switching from geo-redundant backup storage to locally redundant or zone-redundant storage disables geo-restore.

This example code changes the backup storage redundancy to Local:

# Change the backup storage redundancy for Database01 to zone-redundant. 
Set-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -DatabaseName "Database01" -ServerName "Server01" -BackupStorageRedundancy Local

For details, see Set-AzSqlDatabase.

Carefully consider the configuration option for --backup-storage-redundancy when you're creating a Hyperscale database. You can specify storage redundancy only during the database creation process for Hyperscale databases. The selected storage redundancy option will be used for the lifetime of the database for both data storage redundancy and backup storage redundancy. Learn more in Hyperscale backups and storage redundancy.

Existing databases can migrate to different storage redundancy through database copy or point-in-time restore. This example creates a database in the Hyperscale service tier with zone redundancy:

# 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

For syntax details, see New-AzSqlDatabase.

Backup storage redundancy of an existing Hyperscale database can't be updated. However, you can use the database copy command to create a copy of the database. Then you can use the -BackupStorageRedundancy parameter to update the backup storage redundancy.

This example copies a Hyperscale database to a new database by using Gen5 hardware and two vCores. The new database has the backup redundancy set to 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

For syntax details, see New-AzSqlDatabaseCopy. For an overview of database copy, see Copy a transactionally consistent copy of a database in Azure SQL Database.

It's not currently possible to change backup storage redundancy by using the REST API.

• Database backups are an essential part of any business continuity and disaster recovery strategy because they help protect your data from accidental corruption or deletion. To learn about the other business continuity solutions for SQL Database, see Business continuity overview.
• For information about how to configure, manage, and restore from long-term retention of automated backups in Azure Blob Storage by using the Azure portal, see Manage long-term backup retention by using the Azure portal.
• For information about how to configure, manage, and restore from long-term retention of automated backups in Azure Blob Storage by using PowerShell, see Manage long-term backup retention by using PowerShell.
• Get more information about how to restore a database to a point in time by using the Azure portal.
• Get more information about how to restore a database to a point in time by using PowerShell.