Retenção de longo prazo - Base de Dados SQL do Azure e Azure SQL Managed Instance
Aplica-se a:
Banco de Dados SQL do Azure Instância Gerenciada SQLdo Azure
Este artigo fornece uma visão geral conceitual da retenção de longo prazo de backups para o Banco de Dados SQL do Azure e a Instância Gerenciada SQL do Azure. A retenção de longo prazo pode ser configurada por até 10 anos em backups do Banco de Dados SQL do Azure (inclusive na camada de serviço Hyperscale) e da Instância Gerenciada SQL do Azure.
Para começar, consulte Configurar a retenção de backup de longo prazo para o Banco de Dados SQL do Azure e a Instância Gerenciada SQL do Azure.
Como funciona a retenção a longo prazo
Muitos aplicativos têm motivos regulatórios, de conformidade ou outros motivos de negócios que exigem que você mantenha backups de banco de dados além dos 1 a 35 dias fornecidos pelo período de retenção de curto prazo dos backups automáticos. A retenção de backup de longo prazo (LTR) depende dos backups de banco de dados completos que são criados automaticamente pelo serviço SQL do Azure. Para obter mais informações, consulte backups automatizados no Banco de Dados SQL do Azure ou na Instância Gerenciada SQL do Azure.
Usando o recurso LTR, você pode armazenar backups completos especificados do Banco de Dados SQL e da Instância Gerenciada SQL no armazenamento redundante de Blob do Azure com uma política de retenção configurável de até 10 anos. Em seguida, as cópias de segurança LTR podem ser restauradas como uma nova base de dados. Se uma política LTR estiver configurada, os backups automatizados serão copiados para blobs diferentes para armazenamento de longo prazo, que você poderá usar para restaurar o banco de dados para um point-in-time específico. A cópia é um trabalho em segundo plano que não tem impacto no desempenho da carga de trabalho do banco de dados. A política LTR para cada banco de dados no Banco de dados SQL também pode especificar com que frequência os backups LTR são criados.
Nota
Para habilitar o LTR, você pode definir uma política usando uma combinação de quatro parâmetros: retenção de backup semanal (W), retenção de backup mensal (M), retenção de backup anual (Y) e semana do ano (WeekOfYear). Se você especificar W, um backup por semana será copiado para o armazenamento de longo prazo. Se você especificar M, o primeiro backup de cada mês será copiado para o armazenamento de longo prazo. Se você especificar Y, um backup durante a semana especificada por WeekOfYear será copiado para o armazenamento de longo prazo. Se o WeekOfYear especificado estiver no passado quando a política for configurada, o primeiro backup LTR será criado no ano seguinte. Cada backup é mantido em armazenamento de longo prazo de acordo com os parâmetros de política configurados quando o backup LTR é criado.
Qualquer alteração à política LTR aplica-se apenas a futuras cópias de segurança. Por exemplo, se a retenção semanal de cópias de segurança (S), a retenção mensal de cópias de segurança (M) ou a retenção anual de cópias de segurança (A) forem modificadas, a nova definição de retenção só se aplicará às novas cópias de segurança. A retenção de cópias de segurança existentes não será modificada. Se a intenção for eliminar cópias de segurança LTR antigas antes do período de retenção expirar, terá de as eliminar manualmente.
Exemplos da política LTR:
W=0, M=0, Y=5, WeekOfYear=3O terceiro backup completo de cada ano é mantido por cinco anos.
W=0, M=3, Y=0O primeiro backup completo de cada mês é mantido por três meses.
W=12, M=0, Y=0Cada backup completo semanal é mantido por 12 semanas.
W=6, M=12, Y=10, WeekOfYear=20Cada backup completo semanal é mantido por seis semanas. Exceto o primeiro backup completo de cada mês, que é mantido por 12 meses. Exceto o backup completo feito na 20ª semana do ano, que é mantido por 10 anos.
A tabela a seguir ilustra a cadência e a expiração dos backups de longo prazo para a seguinte política:
W=12 weeks (84 dias), (365 dias), (3650 dias), M=12 monthsY=10 yearsWeekOfYear=20 (na semana seguinte a 13 de maio)
As seguintes datas estão na ISO 8601 (YYYY-MM-DD).
| Backup PITR para LTR | Expiração W | Validade M | Validade Y |
|---|---|---|---|
| 2018-03-07 | 2019-07-03 | ||
| 2018-03-14 | 2018-06-06 | ||
| 2018-03-21 | 2018-06-13 | ||
| 2018-03-28 | 2018-06-20 | ||
| 2018-04-04 | 2019-04-25 | ||
| 2018-04-11 | 2018-07-04 | ||
| 2018-04-18 | 2018-07-11 | ||
| 2018-04-25 | 2018-07-18 | ||
| 2018-05-02 | 2019-05-23 | ||
| 2018-05-09 | 01-08-2018 | ||
| 2018-05-16 | 2028-05-13 | ||
| 2018-05-23 | 2018-08-15 | ||
| 2018-05-30 | 2018-08-22 | ||
| 2018-06-06 | 2019-06-20 | ||
| 2018-06-13 | 2018-09-05 | ||
| 2018-06-20 | 2018-09-12 | ||
| 2018-06-27 | 2018-09-19 | ||
| 2018-07-04 | 2019-07-25 | ||
| 2018-07-11 | 2018-10-03 | ||
| 2018-07-18 | 2018-10-10 | ||
| 2018-07-25 | 2018-10-17 | ||
| 2018-08-01 | 2019-08-22 | ||
| 2018-08-08 | 2018-10-31 | ||
| 2018-08-15 | 2018-11-07 | ||
| 2018-08-22 | 2018-11-14 | ||
| 2018-08-29 | 2018-11-21 |
Se você modificar a política acima e definir W=0 (sem backups semanais), o serviço reterá apenas os backups mensais e anuais. Nenhum backup semanal é armazenado sob a política LTR. A quantidade de armazenamento necessária para manter esses backups reduz de acordo.
Importante
O tempo de backups LTR individuais é controlado pelo Banco de Dados SQL do Azure. Não pode criar manualmente uma cópia de segurança LTR nem controlar o tempo da criação das cópias de segurança. Depois de configurar uma política LTR, pode levar até 7 dias até que o primeiro backup LTR apareça na lista de backups disponíveis.
Se você excluir um servidor lógico ou uma instância gerenciada, todos os bancos de dados desse servidor ou instância gerenciada também serão excluídos e não poderão ser recuperados. Não é possível restaurar um servidor excluído ou uma instância gerenciada. No entanto, se você configurou o LTR para um banco de dados ou instância gerenciada, os backups LTR não serão excluídos e poderão ser usados para restaurar bancos de dados em um servidor diferente ou instância gerenciada na mesma assinatura, até um ponto no tempo em que um backup LTR foi feito.
Da mesma forma, se você excluir um banco de dados, os backups LTR não serão excluídos e serão retidos pelo período de retenção configurado. Esses backups podem ser restaurados para o mesmo servidor ou para um servidor diferente na mesma assinatura.
Georreplicação e retenção de cópias de segurança de longo prazo
Se estiver a utilizar grupos de georreplicação ativa ou de ativação pós-falha como solução de continuidade do negócio, deve preparar-se para eventuais ativações pós-falha e configurar a mesma política LTR na instância ou base de dados secundária. O custo de armazenamento LTR não aumenta, pois os backups não são gerados a partir dos secundários. As cópias de segurança só são criadas quando a secundária se torna primária. Ele garante a geração ininterrupta dos backups LTR quando o failover é acionado e o primário é movido para a região secundária.
Nota
Quando o banco de dados primário original se recupera de uma interrupção que causou o failover, ele se torna um novo secundário. Portanto, a criação do backup não será retomada e a política LTR existente não entrará em vigor até que se torne a principal novamente.
Configurar a retenção de cópias de segurança de longa duração
Você pode configurar a retenção de backup de longo prazo usando o portal do Azure e o PowerShell para o Banco de Dados SQL do Azure e a Instância Gerenciada SQL do Azure. Para restaurar um banco de dados a partir do armazenamento LTR, você pode selecionar um backup específico com base em seu carimbo de data/hora. O banco de dados pode ser restaurado para qualquer servidor existente ou instância gerenciada sob a mesma assinatura que o banco de dados original.
Para saber como configurar a retenção de longo prazo ou restaurar um banco de dados do backup para o Banco de Dados SQL usando o portal do Azure ou o PowerShell, consulte Gerenciar retenção de backup de longo prazo do Banco de Dados SQL do Azure.
Para saber como configurar a retenção de longo prazo ou restaurar um banco de dados a partir do backup para a Instância Gerenciada do SQL usando o portal do Azure ou o PowerShell, consulte Gerenciar a retenção de backup de longo prazo da Instância Gerenciada SQL do Azure.
Quando uma solicitação de restauração é iniciada nos últimos 7 dias do período de retenção LTR, o Azure estenderá automaticamente a data de expiração de todos os backups +7 dias, para evitar que um backup LTR expire durante a restauração.
Nota
Se você estiver usando backups LTR para atender a requisitos de conformidade ou outros requisitos de missão crítica, considere a realização de exercícios de recuperação periódicos para verificar se os backups LTR podem ser restaurados e se a restauração resulta no estado esperado do banco de dados.
Conteúdos relacionados
Como os backups de banco de dados protegem os dados contra corrupção ou exclusão acidental, eles são uma parte essencial de qualquer estratégia de continuidade de negócios e recuperação de desastres.
- Visão geral da continuidade de negócios do Banco de Dados SQL do Azure
- Visão geral da continuidade de negócios para a Instância Gerenciada SQL do Azure
- Backups automatizados no Banco de Dados SQL do Azure
- Backups automatizados na Instância Gerenciada SQL do Azure
Para obter um tutorial sobre como configurar e gerenciar backups LTR, visite:
Comentários
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja: https://aka.ms/ContentUserFeedback.
Submeter e ver comentários