Este artigo fornece exemplos para modificar as configurações de backup automatizado para o Azure SQL Database, como a política de retenção de curto prazo e a opção de redundância de armazenamento de backup. Para a Instância Gerenciada SQL do Azure, consulte Alterar configurações de backup automatizado para a Instância Gerenciada SQL do Azure.
Você pode alterar o período de retenção de backup de recuperação point-in-time (PITR) padrão e a frequência de backup diferencial usando o portal do Azure, a CLI do Azure, o PowerShell ou a API REST. Os exemplos seguintes ilustram como alterar a retenção PITR para 28 dias e os backups diferenciais para um intervalo de 24 horas.
Advertência
Se reduzires o período de retenção atual, ficas sem a capacidade de restaurar para pontos mais antigos do que o novo período de retenção. Os backups que não são mais necessários para fornecer PITR dentro do novo período de retenção são excluídos.
Se aumentares o período de retenção atual, não ganharás imediatamente a capacidade de restaurar a pontos temporais mais antigos dentro do novo período de retenção. Você ganha essa capacidade com o tempo, à medida que o sistema começa a reter backups por períodos mais longos.
Para alterar o período de retenção de backup PITR ou a frequência de backup diferencial para bancos de dados ativos usando o portal do Azure:
- Vá para o servidor lógico no Azure com os bancos de dados cujo período de retenção você deseja alterar.
- Selecione Backups no painel esquerdo e, em seguida, selecione a guia Políticas de retenção.
- Selecione os bancos de dados para os quais você deseja alterar a retenção de backup do PITR.
- Selecione Configurar políticas na barra de ações.
- Para alterar o período de retenção para backups de restauração point-in-time, use o controle deslizante em Point-in-time restore.
- Para alterar a frequência de backup diferencial, selecione 12 Horas ou 24 horas na lista suspensa em Frequência de backup diferencial .
Prepare seu ambiente para a CLI do Azure:
Use o ambiente Bash no Azure Cloud Shell. Para mais informações, veja Get started with Azure Cloud Shell.
Se preferir executar comandos de referência da CLI localmente, instale a CLI do Azure. Se você estiver executando no Windows ou macOS, considere executar a CLI do Azure em um contêiner do Docker. Para obter mais informações, consulte Como executar a CLI do Azure em um contêiner do Docker.
Se você estiver usando uma instalação local, entre na CLI do Azure usando o comando az login. Para concluir o processo de autenticação, siga os passos apresentados no seu terminal. Para outras opções de entrada, consulte Autenticar no Azure usando a CLI do Azure.
Quando solicitado, instale a extensão da CLI do Azure na primeira utilização. Para obter mais informações sobre extensões, consulte Usar e gerenciar extensões com a CLI do Azure.
Execute az version para verificar a versão e as bibliotecas dependentes instaladas. Para atualizar para a versão mais recente, execute o comando az upgrade.
Altere a retenção de backup PITR e a frequência de backup diferencial para bancos de dados ativos usando o exemplo a seguir:
# 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
Para alterar a retenção de backup PITR e a frequência de backup diferencial para bancos de dados ativos, use o seguinte exemplo do PowerShell:
# 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
Pedido de amostra
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
Corpo do pedido
{
"properties":{
"retentionDays":28,
"diffBackupIntervalInHours":24
}
}
Resposta da amostra
{
"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
}
}
Para obter mais informações, consulte API REST de retenção de backup.
Você pode configurar a redundância de armazenamento de backup para bancos de dados no Banco de Dados SQL do Azure ao criar seu banco de dados. Você também pode alterar a redundância de armazenamento depois que o banco de dados já estiver criado.
As alterações de redundância de armazenamento de backup feitas em bancos de dados existentes aplicam-se apenas a backups futuros. O valor padrão é armazenamento com redundância geográfica. Para obter as diferenças de preços entre armazenamento de backup com redundância local, com redundância de zona e com redundância geográfica, consulte a página de preços do Banco de dados SQL .
A redundância de armazenamento para bancos de dados Hyperscale é exclusiva. Para saber mais, reveja a redundância de armazenamento de backup em hiperescala .
No portal do Azure, você pode escolher uma opção de redundância de armazenamento de backup ao criar seu banco de dados. Mais tarde, você pode atualizar a redundância de armazenamento de backup na página Compute & storage das configurações do banco de dados.
Ao criar o seu banco de dados, escolha a opção de redundância de armazenamento de backup na aba Noções básicas.
Para bancos de dados existentes, acesse o seu banco de dados no portal do Azure. Selecione Armazenamento em Definições & Computaçãoe, em seguida, escolha a opção desejada para redundância de armazenamento de backup.
Para configurar a redundância de armazenamento de backup ao criar um novo banco de dados, você pode especificar o parâmetro --backup-storage-redundancy com o comando az sql db create. Os valores possíveis são Geo, Zonee Local.
Por padrão, todos os bancos de dados no Banco de Dados SQL do Azure usam armazenamento com redundância geográfica para backups. A restauração geográfica será desabilitada se um banco de dados for criado ou atualizado com armazenamento de backup com redundância local ou de zona.
Este exemplo cria um banco de dados na camada de serviço de uso geral com redundância de backup local:
az sql db create \
--resource-group myresourcegroup \
--server myserver \
--name mydb \
--tier GeneralPurpose \
--backup-storage-redundancy Local
Exceto para bancos de dados Hyperscale e Basic, você pode atualizar a configuração de redundância de armazenamento de backup para um banco de dados existente usando o parâmetro --backup-storage-redundancy e o comando az sql db update. Pode levar até 48 horas para que as alterações sejam aplicadas no banco de dados. A mudança do armazenamento de backup com redundância geográfica para o armazenamento com redundância local ou com redundância de zona desativa a restauração geográfica.
Este código de exemplo altera a redundância de armazenamento de backup para Local:
az sql db update \
--resource-group myresourcegroup \
--server myserver \
--name mydb \
--backup-storage-redundancy Local
Hiperescala
Considere cuidadosamente a opção de configuração para --backup-storage-redundancy ao criar um banco de dados Hyperscale. A redundância de armazenamento pode ser especificada somente durante o processo de criação de banco de dados para bancos de dados Hyperscale. Não é possível atualizá-lo mais tarde. A opção de redundância de armazenamento selecionada será usada durante o tempo de vida do banco de dados para redundância de armazenamento de dados e redundância de armazenamento de backup. Saiba mais em Redundância de armazenamento de backup em hiperescala.
Os bancos de dados de camada de serviço Hyperscale existentes podem migrar para redundância de armazenamento diferente por meio da replicação geográfica ativa, o que causa um tempo de inatividade mínimo. Como alternativa, pode migrar para uma redundância de armazenamento diferente usando cópia de banco de dados ou restauração para um ponto no tempo. Este exemplo cria um banco de dados na camada de serviço Hyperscale com redundância de zona:
az sql db create \
--resource-group myresourcegroup \
--server myserver \
--name mydb \
--tier Hyperscale \
--backup-storage-redundancy Zone
Para obter mais informações, consulte az sql db create e az sql db update.
Não é possível atualizar diretamente a redundância de armazenamento de backup de um banco de dados Hyperscale. No entanto, você pode alterá-lo usando o comando de cópia de banco de dados com o parâmetro --backup-storage-redundancy. Este exemplo copia um banco de dados Hyperscale para um novo banco de dados que usa hardware Gen5 e dois vCores. O novo banco de dados tem a redundância de backup definida como 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
Para obter detalhes de sintaxe, consulte az sql db copy. Para obter uma visão geral da cópia do banco de dados, consulte Copiar uma cópia transacional consistente de um banco de dados no Banco de Dados SQL do Azure.
Para configurar a redundância de armazenamento de backup ao criar um novo banco de dados, especifique o parâmetro -BackupStorageRedundancy com o cmdlet New-AzSqlDatabase. Os valores possíveis são Geo, Zonee Local. Por padrão, todos os bancos de dados no Banco de Dados SQL do Azure usam armazenamento com redundância geográfica para backups. A restauração geográfica será desabilitada se um banco de dados for criado com armazenamento de backup com redundância local ou de zona.
Este exemplo cria um banco de dados na camada de serviço de uso geral com redundância de backup local:
# 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
Exceto para bancos de dados Hyperscale e Basic, você pode usar o parâmetro -BackupStorageRedundancy com o cmdlet Set-AzSqlDatabase para atualizar a configuração de redundância de armazenamento de backup para um banco de dados existente. Os valores possíveis são Geo, Zonee Local. Pode levar até 48 horas para que as alterações sejam aplicadas no banco de dados. A mudança do armazenamento de backup com redundância geográfica para o armazenamento com redundância local ou com redundância de zona desativa a restauração geográfica.
Este código de exemplo altera a redundância de armazenamento de backup para Local:
# Change the backup storage redundancy for Database01 to zone-redundant.
Set-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -DatabaseName "Database01" -ServerName "Server01" -BackupStorageRedundancy Local
Para obter detalhes, consulte Set-AzSqlDatabase.
Hiperescala
Considere cuidadosamente a opção de configuração para --backup-storage-redundancy ao criar um banco de dados Hyperscale. Você pode especificar redundância de armazenamento somente durante o processo de criação de banco de dados para bancos de dados Hyperscale. A opção de redundância de armazenamento selecionada será usada durante o tempo de vida do banco de dados para redundância de armazenamento de dados e redundância de armazenamento de backup. Saiba mais em sobre backups em hiperescala e redundância de armazenamento.
Os bancos de dados existentes podem migrar para diferentes redundâncias de armazenamento por meio de cópia do banco de dados ou restauração em um ponto no tempo. Este exemplo cria um banco de dados na camada de serviço Hyperscale com redundância de 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
Para obter detalhes de sintaxe, consulte New-AzSqlDatabase.
A redundância de armazenamento de backup de um banco de dados Hyperscale existente não pode ser atualizada. No entanto, você pode usar o comando database copy para criar uma cópia do banco de dados. Em seguida, você pode usar o parâmetro -BackupStorageRedundancy para atualizar a redundância de armazenamento de backup.
Este exemplo copia um banco de dados Hyperscale para um novo banco de dados usando hardware Gen5 e dois vCores. O novo banco de dados tem a redundância de backup definida como 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
Para obter detalhes de sintaxe, consulte New-AzSqlDatabaseCopy. Para obter uma visão geral da cópia do banco de dados, consulte Copiar uma cópia transacional consistente de um banco de dados no Banco de Dados SQL do Azure.
Observação
Para usar o parâmetro -BackupStorageRedundancy com restauração de banco de dados, cópia de banco de dados ou criar operações secundárias, use a versão Az.Sql 2.11.0 ou posterior do Azure PowerShell.
Atualmente, não é possível alterar a redundância do armazenamento de backup usando a API REST.
do Banco de Dados SQL do Azure
