Backups de retenção a longo prazo - Base de Dados SQL do Azure e Azure SQL Managed Instance

Aplica-se a: Base de Dados SQL do AzureAzure SQL Managed Instance

Este artigo fornece uma visão conceptual dos backups de retenção a longo prazo (LTR) para Base de Dados SQL do Azure e Azure SQL Managed Instance. A retenção a longo prazo pode ser configurada por até 10 anos em backups do Base de Dados SQL do Azure (incluindo no nível de serviço Hyperscale) e do Azure SQL Managed Instance.

Para começar a usar o recurso de backup de retenção de longo prazo, consulte:

Importante

Algumas APIs mais antigas usadas para operações de backup de retenção a longo prazo (LTR) estão obsoletas e já não são suportadas. Evite usar comandos legados do PowerShell como Copy-AzSqlDatabaseLongTermRetentionBackup. Use antes os métodos de restauração suportados descritos neste artigo.

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 backups a longo prazo (LTR) baseia-se nos backups completos da base de dados que são automaticamente criados pelo serviço SQL do Azure. Para mais informações, consulte Backups automatizados em Base de Dados SQL do Azure ou Backups automatizados em Azure SQL Managed Instance.

Ao usar a funcionalidade LTR, pode armazenar backups completos especificados da base de dados SQL e do SQL Managed Instance em armazenamento redundante do Azure Blob com uma política de retenção configurável 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. O processo de 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 também pode especificar com que frequência os backups LTR são criados.

Observação

  • No Base de Dados SQL do Azure, pode configurar backups de retenção a longo prazo como imutáveis.
  • No Azure SQL Managed Instance, atualmente não é possível configurar backups como imutável. Backups LTR não são modificáveis, mas podes eliminá-los através do portal Azure, CLI do Azure, PowerShell ou API REST. Como solução alternativa no Azure SQL Managed Instance, pode realizar backups de bases de dados copy-only e guardá-los na sua própria conta Armazenamento do Azure como um ficheiro imutável.

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.

As alterações na política LTR aplicam-se apenas a backups futuros. Por exemplo, se você modificar a retenção de backup semanal (W), a retenção de backup mensal (M) ou a retenção de backup anual (Y), a nova configuração de retenção só se aplicará a novos backups. A retenção de backups existentes não é modificada. A política LTR pode ser configurada para cada base de dados no Base de Dados SQL do Azure e no Azure SQL Managed Instance. Se você pretende excluir backups LTR antigos antes que o período de retenção expire, você pode excluir manualmente os backups.

Observação

Tanto no Base de Dados SQL do Azure como no Azure SQL Managed Instance, quando ativas uma política LTR pela primeira vez para uma base de dados, o backup completo mais recente do ponto de restauro no tempo (PITR) é copiado para armazenamento a longo prazo.

Exemplos da política LTR:

  • W=0, M=0, Y=5, WeekOfYear=3

    O terceiro backup completo de cada ano é mantido por cinco anos.

  • W=0, M=3, Y=0

    O primeiro backup completo de cada mês é mantido por três meses.

  • W=12, M=0, Y=0

    Cada backup completo semanal é mantido por 12 semanas.

  • W=6, M=12, Y=10, WeekOfYear=20

    Cada 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), M=12 months (365 dias), Y=10 years (3.650 dias), WeekOfYear=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-03-02
2018-03-14 2018-06-06
2018-03-21 2018-06-13
2018-03-28 2018-06-20
2018-04-04 2019-03-30
2018-04-11 2018-07-04
2018-04-18 2018-07-11
2018-04-25 2018-07-18
2018-05-02 2019-04-27
2018-05-09 01-08-2018
2018-05-16 13-05-2028
2018-05-23 2018-08-15
2018-05-30 2018-08-22
2018-06-06 2019-06-01
2018-06-13 2018-09-05
2018-06-20 2018-09-12
2018-06-27 2018-09-19
2018-07-04 2019-06-29
2018-07-11 2018-10-03
2018-07-18 2018-10-10
2018-07-25 2018-10-17
01-08-2018 2019-07-27
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 essa política e definir W=0 (sem backups semanais), os backups semanais serão mantidos até expirarem e, em seguida, o serviço reterá apenas os backups mensais e anuais. Nenhum backup semanal futuro é armazenado sob a política LTR. A quantidade de armazenamento necessária para manter esses backups diminui proporcionalmente.

Importante

O momento dos backups LTR individuais é controlado pela Microsoft. Não pode criar manualmente uma cópia de segurança LTR nem controlar o tempo da criação de cópias de segurança. Depois de configurar uma política LTR, pode levar até sete 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 pelo SQL, todos os bancos de dados desse servidor ou instância gerenciada também serão excluídos. Não é possível restaurar um servidor lógico excluído ou uma instância gerenciada pelo SQL. No entanto, se você configurou o LTR para um banco de dados, os backups LTR não serão excluídos e poderão ser usados para restaurar bancos de dados para 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 você estiver usando grupos ativos de replicação geográfica ou failover como sua solução de continuidade de negócios, prepare-se para eventuais failovers e configure a mesma política LTR no banco de dados ou instância secundária que você tem no principal. O custo de armazenamento LTR não aumenta, pois os backups não são gerados a partir de secundários. Os backups só são criados depois de o secundário se tornar primário para garantir a geração ininterrupta de backups LTR quando um failover é acionado e o primário é movido para a região secundária.

Quando o banco de dados primário original se recupera de uma interrupção que causou o failover, ele se torna o novo secundário. Portanto, a criação de backup não será retomada no novo secundário e a política LTR existente não entrará em vigor até que se torne a principal novamente.

Perímetro de segurança de rede e restauro LTR (pré-visualização)

Observação

Um perímetro de segurança de rede (pré-visualização) aplica-se apenas ao Base de Dados SQL do Azure. O Azure SQL Managed Instance não é um recurso integrado, por isso esta secção não se aplica a ele. Para a lista atual, consulte Recursos de ligação privada integrados.

A restauração LTR é uma operação gerida por plataforma que restaura uma base de dados de um backup de longo prazo para um servidor lógico alvo. Quando qualquer um dos servidores lógicos pertence a um perímetro, a restauração está sujeita às regras de acesso do perímetro.

O serviço verifica o acesso de saída no servidor de origem, quando esse servidor ainda existe, e o acesso de entrada no servidor de destino. Se o servidor lógico de origem foi eliminado, apenas a verificação de entrada do lado alvo pode ser executada.

Configurações suportadas

A restauração do LTR funciona tanto em modo transição como em modo forçado. No modo de transição, as restaurações têm sucesso sem regras de acesso. Configura as regras antes de mudares para o modo forçado.

No modo forçado, estas configurações são suportadas:

Servidor de origem Servidor de destino Regras de acesso necessárias
Dentro de um perímetro No mesmo perímetro None. O acesso entre recursos no mesmo perímetro é sempre permitido.
Dentro de um perímetro Num perímetro diferente De saída na origem, de entrada no destino.
Dentro de um perímetro Não num perímetro De saída na fonte.
Não num perímetro Dentro de um perímetro A dirigir-se para o alvo.
Eliminados Dentro de um perímetro A entrar no alvo.
Fora de um perímetro Fora de um perímetro None.

A restauração LTR não requer uma identidade gerida.

Configurar regras de acesso para uma restauração LTR

  1. Associe cada servidor lógico ao seu perímetro , caso ainda não o tenha feito. Ignora este passo para um servidor que fica fora de um perímetro ou para um servidor de origem eliminado.
  2. Se o servidor de origem estiver num perímetro e o servidor de destino não estiver no mesmo perímetro, adicione uma regra de saída no perfil de origem com Tipo de destino definido para FQDN e o nome de domínio totalmente qualificado do servidor de destino.
  3. Se o servidor alvo estiver num perímetro e o servidor de origem não estiver no mesmo perímetro, adicione uma regra de entrada no perfil alvo. O pedido de restauro vem da infraestrutura de gestão SQL do Azure, não do servidor de origem. Na regra, permita uma destas origens:
    • O ID de subscrição do servidor de origem (recomendado).
    • A service tag (recomendada).
    • Intervalos de endereços IP. Para a cloud pública, Azure IP Ranges and Service Tags - Public Cloud lista cada service tag e os seus intervalos de endereços IP. O nome da etiqueta de serviço é SqlManagement. A Microsoft não publica estes intervalos por região, por isso permita-os todos.
  4. Com os servidores ainda em modo de transição, execute uma restauração e verifique os registos de diagnóstico do perímetro de segurança da rede para recusas inesperadas.
  5. Só mude para o modo imposto depois de todas as verificações de diagnóstico terem passado.

Limitações e diferenças de comportamento

  • Não se pode eliminar um servidor lógico que tenha backups LTR enquanto a sua associação ao perímetro está em modo imposto. Backups LTR imutáveis também bloqueiam a eliminação, quer o servidor esteja ou não num perímetro. Para mais informações, consulte Backups de longo prazo imutáveis e eliminação de servidores lógicos.
  • Se eliminar um servidor de origem enquanto a sua associação está em modo de transição, o serviço já não consegue ler os metadados perimetrais desse servidor, pelo que só pode validar o lado alvo da restauração. Tenha em conta esta lacuna se depender da validação do lado da fonte como controlo.
  • No modo de transição, uma restauração é bem-sucedida mesmo quando as regras necessárias estão em falta. Em modo imposto, a mesma restauração é bloqueada.

Configurar retenção de backup de longo prazo

Importante

Algumas APIs mais antigas usadas para operações de backup de retenção a longo prazo (LTR) estão obsoletas e já não são suportadas. Evite usar comandos legados do PowerShell como Copy-AzSqlDatabaseLongTermRetentionBackup. Use antes os métodos de restauração suportados descritos neste artigo.

Pode configurar a retenção de backups a longo prazo usando o portal Azure e o PowerShell for Base de Dados SQL do Azure e Azure SQL Managed Instance. Para restaurar um banco de dados a partir do armazenamento LTR, pode selecionar um backup específico com base na data e hora. A base de dados pode ser restaurada em qualquer servidor ou instância gerida existente sob a mesma subscrição da base de dados original. Para uma lista completa de capacidades de restauro, limitações e funcionalidades, consulte Capacidades e funcionalidades de restauro em Azure SQL Managed Instance.

Quando uma solicitação de restauração é iniciada nos últimos sete dias do período de retenção LTR, o backup LTR só é excluído após a conclusão da operação de restauração, mesmo que o período de retenção tenha expirado.

Observação

Restaurar bases de dados entre o nível de serviço Hyperscale e os outros níveis de serviço do Base de Dados SQL do Azure não é atualmente suportado.

Em Azure SQL Managed Instance, pode usar trabalhos SQL Agent para agendar backups de base de dados apenas com cópia e transferi-los para a sua própria conta de armazenamento como alternativa a:

  • Mantenha backups por mais de 10 anos.
  • Mantenha cópias diárias de seus bancos de dados por mais de 35 dias.
  • Armazene backups de banco de dados em armazenamento imutável.

Sugestão

Se você estiver usando backups LTR para atender à conformidade ou a 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.

Observação

Os backups LTR dependem de backups completos efetuados com êxito. Um registo completo de transações pode impedir uma cópia de segurança completa agendada, o que pode impedir uma cópia de segurança de longo prazo. A captura de dados de alteração (CDC) e outras funcionalidades que impedem o truncamento dos registos de transações podem atrasar um backup LTR, que só tem sucesso após o sucesso do backup completo. Avalie funcionalidades que previnam o truncamento dos registos de transações e considere desativá-las temporariamente até que as operações de backup recuperem.

Próximo passo

Gerir a retenção de backups a longo prazo do Base de Dados SQL do Azure

Gere a retenção de backups a longo prazo no Azure SQL Managed Instance

Conteúdo relacionado

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.

  • Última atualização a