Altere o período de retenção de backup PITR (recuperação pontual 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 a seguir ilustram como alterar a retenção de PITR para 28 dias e os backups diferenciais para um intervalo de 24 horas.
Aviso
Se você reduzir o período de retenção atual, perderá a capacidade de restaurar para pontos no tempo mais antigos do que o novo período de retenção. Os backups que não são mais necessários para fornecer PITR no novo período de retenção são excluídos.
Ao aumentar o período de retenção atual, você não ganha imediatamente a capacidade de restauração para pontos mais antigos no novo período de retenção. Essa capacidade é obtida ao longo do 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 e a frequência de backup diferencial dos bancos de dados ativos usando o portal do Azure:
- Acesse 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 escolha a guia Políticas de retenção.
- Selecione os bancos de dados nos quais você deseja alterar a retenção de backup da PITR.
- Selecione Configurar políticas na barra de ações.
- Para alterar o período de retenção para backups de restauração pontual, use o controle deslizante em Restauração pontual.
- Para alterar a frequência de backup diferencial, selecione 12 Horas ou 24 horas no menu suspenso em Frequência de backup diferencial .
Preparar o ambiente para a CLI do Azure:
Use o ambiente Bash no Azure Cloud Shell. Para obter mais informações, confira Início Rápido para Bash no Azure Cloud Shell.
Se preferir executar os comandos de referência da CLI localmente, instale a CLI do Azure. Para execuções no Windows ou no macOS, considere executar a CLI do Azure em um contêiner do Docker. Para obter mais informações, confira Como executar a CLI do Azure em um contêiner do Docker.
Se estiver usando uma instalação local, entre com a CLI do Azure usando o comando az login. Para concluir o processo de autenticação, siga as etapas exibidas no terminal. Para ver outras opções de entrada, confira Conectar-se com a CLI do Azure.
Quando solicitado, instale a extensão da CLI do Azure no primeiro uso. Para obter mais informações sobre extensões, confira Usar extensões com a CLI do Azure.
Execute az version para localizar a versão e as bibliotecas dependentes que estão instaladas. Para fazer a atualização para a versão mais recente, execute az upgrade.
Altere a retenção de backup PITR e a frequência de backup diferencial para os bancos de dados ativos usando o seguinte exemplo:
# 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 os 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
Solicitação de exemplo
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 da solicitação
{
"properties":{
"retentionDays":28,
"diffBackupIntervalInHours":24
}
}
Resposta de exemplo
{
"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, confira API REST de retenção de backup.
Você pode configurar a redundância de armazenamento de backup dos 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á foi criado.
As alterações de redundância de armazenamento de backup feitas em bancos de dados existentes só se aplicam aos backups futuros. O valor padrão é armazenamento com redundância geográfica. Para ver as diferenças de preços entre o armazenamento de backup com redundância local, com redundância de zona e com redundância geográfica, acesse a página de preços do Banco de Dados SQL.
No portal do Azure, você pode escolher uma opção de redundância de armazenamento de backup ao criar seu banco de dados. Posteriormente, você pode atualizar a redundância de armazenamento de backup na página Computação e armazenamento das configurações do banco de dados.
Quando estiver criando o banco de dados, escolha a opção de redundância de armazenamento de backup na guia Informações básicas.
Para os bancos de dados existentes, acesse o banco de dados no portal do Azure. Selecione Computação e armazenamento em Configurações e escolha a opção desejada para a redundância de armazenamento de backup.
Para configurar a redundância de armazenamento de backup ao criar um banco de dados, especifique o parâmetro --backup-storage-redundancy com o comando az sql db create. Os valores possíveis são Geo, Zone e Local.
Por padrão, todos os bancos de dados no Banco de Dados SQL do Azure usam o 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 o armazenamento de backup com redundância local ou com redundância de zona.
Este exemplo cria um banco de dados na camada de serviço 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 os bancos de dados do Básico e da Hiperescala, você pode atualizar a configuração de redundância de armazenamento de backup de um banco de dados existente usando o parâmetro --backup-storage-redundancy e o comando az sql db update. Podem ser necessárias até 48 horas para que as alterações sejam aplicadas no banco de dados. A alternância do armazenamento de backup com redundância geográfica para o armazenamento com redundância local ou com redundância de zona desabilita 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 de --backup-storage-redundancy ao criar um banco de dados da Hiperescala. A redundância de armazenamento só pode ser especificada durante o processo de criação de bancos de dados da Hiperescala. Você pode atualizá-la mais tarde. A opção de redundância de armazenamento selecionada será usada para o tempo de vida do banco de dados tanto para redundância de armazenamento quanto para redundância de armazenamento de backup. Saiba mais em Redundância de armazenamento de backup da Hiperescala.
Os bancos de dados da Hiperescala existentes podem migrar para outro tipo de redundância de armazenamento por meio da replicação geográfica ativa, o que causa um tempo de inatividade mínimo. Como alternativa, você pode migrar para outro tipo de redundância de armazenamento usando a cópia do banco de dados ou a restauração pontual. Este exemplo cria um banco de dados na camada de serviço Hiperescala com a 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 a redundância de armazenamento de backup de um banco de dados da Hiperescala diretamente. No entanto, você pode alterá-la usando o comando database copy com o parâmetro --backup-storage-redundancy. Este exemplo copia um banco de dados da Hiperescala para um novo banco de dados que usa o 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 ter uma visão geral da cópia do banco de dados, confira Fazer uma cópia transacionalmente 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 banco de dados, você pode especificar o parâmetro -BackupStorageRedundancy com o cmdlet New-AzSqlDatabase. Os valores possíveis são Geo, Zone e Local. Por padrão, todos os bancos de dados no Banco de Dados SQL do Azure usam o armazenamento com redundância geográfica para backups. A restauração geográfica será desabilitada se um banco de dados for criado com o armazenamento de backup com redundância local ou com redundância de zona.
Este exemplo cria um banco de dados na camada de serviço 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 os bancos de dados do Básico e da Hiperescala, você pode usar o parâmetro -BackupStorageRedundancy com o cmdlet Set-AzSqlDatabase para atualizar a configuração de redundância de armazenamento de backup de um banco de dados existente. Os valores possíveis são Geo, Zone e Local. Podem ser necessárias até 48 horas para que as alterações sejam aplicadas no banco de dados. A alternância do armazenamento de backup com redundância geográfica para o armazenamento com redundância local ou com redundância de zona desabilita 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 ver os detalhes, acesse Set-AzSqlDatabase.
Hiperescala
Considere cuidadosamente a opção de configuração de --backup-storage-redundancy ao criar um banco de dados da Hiperescala. Você só pode especificar a redundância de armazenamento durante o processo de criação de bancos de dados da Hiperescala. A opção de redundância de armazenamento selecionada será usada para o tempo de vida do banco de dados tanto para redundância de armazenamento quanto para redundância de armazenamento de backup. Saiba mais em backups de Hiperescala e redundância de armazenamento.
Os bancos de dados existentes podem migrar para outro tipo de redundância de armazenamento usando a cópia do banco de dados ou a restauração pontual. Este exemplo cria um banco de dados na camada de serviço Hiperescala com a 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 ver os detalhes da sintaxe, acesse New-AzSqlDatabase.
A redundância de armazenamento de backup de um banco de dados da Hiperescala 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 da Hiperescala para um novo banco de dados usando o 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 ver os detalhes da sintaxe, acesse New-AzSqlDatabaseCopy. Para ter uma visão geral da cópia do banco de dados, confira Fazer uma cópia transacionalmente consistente de um banco de dados no Banco de Dados SQL do Azure.
Observação
Para usar o parâmetro -BackupStorageRedundancy com as operações de restauração de banco de dados, cópia de banco de dados ou criar secundário, use o Azure PowerShell versão Az.Sql 2.11.0 ou posterior.
No momento, não é possível alterar a redundância de armazenamento de backup usando a API REST.
Banco de Dados SQL do Azure