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 a seguir ilustram como alterar a retenção 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. As cópias de segurança que já não são necessárias para fornecer o PITR no novo período de retenção são eliminadas.
Se você aumentar o período de retenção atual, não ganhará imediatamente a capacidade de restaurar para pontos mais antigos no tempo dentro do novo período de retenção. Esta capacidade é ganha ao longo do tempo, à medida que o sistema começa a reter cópias de segurança 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 Restauração point-in-time.
- Para alterar a frequência de backup diferencial, selecione 12 horas ou 24 horas no menu suspenso em Frequência de backup diferencial .
Prepare seu ambiente para a CLI do Azure:
Use o ambiente Bash no Azure Cloud Shell. Para obter mais informações, consulte Guia de início rápido para Bash no Azure Cloud Shell.
Se preferir executar comandos de referência da CLI localmente, instale a CLI do Azure. Se estiver a utilizar o Windows ou macOS, considere executar a CLI do Azure num contentor Docker. Para obter mais informações, consulte Como executar a CLI do Azure em um contêiner do Docker.
Se estiver a utilizar uma instalação local, inicie sessão no CLI do Azure ao utilizar 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 Entrar com a CLI do Azure.
Quando solicitado, instale a extensão da CLI do Azure na primeira utilização. Para obter mais informações sobre as extensões, veja Utilizar extensões com o CLI do Azure.
Execute o comando az version para localizar 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, consulte 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 seu banco de dados, escolha a opção de redundância de armazenamento de backup na guia Noções básicas .
Para bancos de dados existentes, vá para seu banco de dados no portal do Azure. Selecione Computação & armazenamento em Configurações e, 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 com o --backup-storage-redundancy az sql db create comando. 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 e o --backup-storage-redundancy az sql db update comando. 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
Hyperscale
Considere cuidadosamente a opção de configuração para --backup-storage-redundancy quando estiver criando 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 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, você pode migrar para uma redundância de armazenamento diferente usando cópia de banco de dados ou restauração point-in-time. 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 database copy com o --backup-storage-redundancy parâmetro. 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 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 novo banco de dados, você pode especificar o parâmetro com o -BackupStorageRedundancy New-AzSqlDatabase cmdlet. 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 com o -BackupStorageRedundancy Set-AzSqlDatabase cmdlet 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.
Hyperscale
Considere cuidadosamente a opção de configuração para --backup-storage-redundancy quando estiver criando 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 Backups em hiperescala e redundância de armazenamento.
Os bancos de dados existentes podem migrar para redundância de armazenamento diferente por meio de cópia de banco de dados ou restauração point-in-time. 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 -BackupStorageRedundancy parâmetro 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 transacionalmente consistente de um banco de dados no Banco de Dados SQL do Azure.
Nota
Para usar o parâmetro com restauração de banco de dados, cópia de banco de dados ou criar operações secundárias, use a -BackupStorageRedundancy 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.
Banco de Dados SQL do Azure