Backups automatizados no Banco de Dados SQL do Azure

Aplica-se a: Banco de Dados SQL do Azure

• Banco de Dados SQL do Azure
• Instância Gerenciada do SQL do Azure

Este artigo descreve o recurso de backup automatizado para o Banco de Dados SQL do Azure.

Para alterar as configurações de backup, confira Alterar configurações. Para restaurar um backup, confira Recuperação por meio de backups de banco de dados automatizados.

O que é um backup de banco de dados?

Os backups de banco de dados são uma parte essencial de qualquer estratégia de continuidade dos negócios e recuperação de desastres, porque protegem seus dados de serem excluídos ou corrompidos. Esses backups permitem a restauração do banco de dados para um ponto no tempo dentro do período de retenção configurado. Se as suas regras de proteção de dados exigirem que os backups fiquem disponíveis por um tempo estendido (até dez anos), configure uma LTR (retenção de longo prazo) para bancos de dados individuais e em pool.

Para camadas de serviço diferentes da Hiperescala, o Banco de Dados SQL do Azure usa a tecnologia de mecanismo do SQL Server para fazer backup e restaurar dados. Os bancos de dados da Hiperescala usam backup e restauração com base em instantâneos de armazenamento. Com a tecnologia de backup tradicional do SQL Server, os bancos de dados maiores têm tempos longos de backup/restauração. Com o uso de instantâneos, a Hiperescala fornece recursos de backup instantâneo e restauração rápida, independentemente do tamanho do banco de dados. Para obter mais informações, confira Backups de Hiperescala.

Frequência de backup

O Banco de Dados SQL do Azure cria:

• Backups completos toda semana.
• Backups diferenciais a cada 12 ou 24 horas.
• Backups de log de transações a cada dez minutos, aproximadamente.

A frequência exata dos backups de logs de transações é baseada no tamanho da computação e na quantidade de atividade do banco de dados. Quando você restaura um banco de dados, o serviço determina quais backups completos, diferenciais e de log de transações precisam ser restaurados.

A arquitetura da Hiperescala não requer backups completos, diferenciais ou de log. Para obter mais informações, confira Backups de Hiperescala.

Redundância do armazenamento de backup

O mecanismo de redundância de armazenamento armazena várias cópias dos seus dados para que eles sejam protegidos contra eventos planejados e não planejados. Esses eventos podem incluir falhas de hardware transitórias, falhas de rede ou de energia ou desastres naturais de grande porte.

Por padrão, novos bancos de dados no Banco de Dados SQL do Azure armazenam backups em blobs de armazenamento com redundância geográfica que são replicados para uma região emparelhada. A redundância geográfica ajuda na proteção contra interrupções que afetam o armazenamento de backup na região primária. Ele também permite que você restaure seus bancos de dados em uma região diferente no caso de uma interrupção regional.

O portal do Azure fornece uma opção de Ambiente de carga de trabalho que ajuda a predefinir algumas definições de configuração. Essas configurações podem ser substituídas. Essa opção se aplica somente à página do portal Criar Banco de Dados SQL.

• A escolha do ambiente de carga de trabalho de desenvolvimento define a opção de Redundância de armazenamento de backup para usar o armazenamento com redundância local. O armazenamento com redundância local gera menos custos e é apropriado para ambientes de pré-produção que não exigem redundância do armazenamento com replicação de zona ou replicação geográfica.
• A escolha do ambiente de carga de trabalho de Produção define a Redundância do armazenamento de backup como armazenamento com redundância geográfica, a opção padrão.
• A opção de Ambiente de carga de trabalho também altera a configuração inicial da computação, embora isso possa ser substituído. Caso contrário, a opção de Ambiente de carga de trabalho não terá impacto no licenciamento ou em outras definições de configuração de bancos de dados.

Para garantir que os backups permaneçam na mesma região em que o banco de dados está implantado, altere a redundância de armazenamento de backup do armazenamento com redundância geográfica padrão para outros tipos de armazenamento que mantêm seus dados na região. A redundância de armazenamento de backup configurada é aplicada a backups STR (retenção de curto prazo) e backups LTR. Para saber mais sobre redundância de armazenamento, confira Redundância de dados.

Você pode configurar a redundância de armazenamento de backup ao criar seu banco de dados e pode atualizá-lo posteriormente. As alterações feitas em um banco de dados existente só se aplicam aos backups futuros. Depois que você atualizar a redundância de armazenamento de backup de um banco de dados existente, poderá levar até 48 horas para que as alterações sejam aplicadas.

Você pode escolher uma das seguintes opções de redundância de armazenamento para backups:

• LRS (armazenamento com redundância local): copia seus backups de maneira síncrona três vezes em um só local físico na região primária. O LRS é a opção de armazenamento mais barata, mas não recomendamos isso para aplicativos que exigem resiliência a interrupções regionais ou uma garantia de alta durabilidade de dados.

  

• ZRS (armazenamento com redundância de zona): copia seus backups de maneira síncrona em três zonas de disponibilidade do Azure na região primária. No momento, está disponível em algumas regiões.

  

• GRS (armazenamento com redundância geográfica): copia seus backups de maneira síncrona três vezes em um só local físico na região primária usando o LRS. Em seguida, ele copia os dados de maneira assíncrona para um só local físico na região secundária emparelhada.

  O resultado é:

  • Três cópias síncronas na região primária.
  • Três cópias síncronas na região emparelhada que foram feitas da região primária para a região secundária de maneira assíncrona.

  

• GZRS (armazenamento com redundância de zona geográfica): o armazenamento com redundância de zona geográfica (GZRS) combina a alta disponibilidade fornecida pela redundância entre zonas de disponibilidade (ZRS) com a proteção contra interrupções regionais fornecidas pela replicação geográfica (GRS). Copia seus backups de forma síncrona em três zonas de disponibilidade do Azure na região primária e, de forma assíncrona, três vezes para um único local físico na região secundária emparelhada.

  A Microsoft recomenda o uso do GZRS para aplicativos que exigem consistência, durabilidade e disponibilidade máximas, excelente desempenho e resiliência para recuperação de desastres.

  O resultado é:

  • Três cópias síncronas em zonas de disponibilidade, na região primária.

  • Três cópias síncronas na região emparelhada, copiadas de forma assíncrona da região primária para a região secundária.

    O diagrama a seguir mostra como os dados são replicados com o GZRS ou com o RA-GZRS:

  

Aviso

• A restauração geográfica é desabilitada assim que um banco de dados é atualizado para usar o armazenamento com redundância local ou com redundância de zona.
• Todos os diagramas de redundância de armazenamento mostram as regiões com várias zonas de disponibilidade. No entanto, há algumas regiões que fornecem apenas uma única zona de disponibilidade e não dão suporte ao ZRS.
• A redundância de armazenamento de backup para bancos de dados de Hiperescala só pode ser definida durante a criação. Não será possível modificar essa configuração depois que o recurso for provisionado. Para atualizar as configurações de redundância de armazenamento de backup para um banco de dados de Hiperescala existente com tempo mínimo de inatividade, use a replicação geográfica ativa. Como alternativa, você pode usar a cópia do banco de dados. Saiba mais em backups de Hiperescala e redundância de armazenamento.

Uso do backup

Você pode usar backups criados automaticamente nos seguintes cenários:

• Restaurar um banco de dados existente em um momento específico dentro do período de retenção usando o portal do Azure, o Azure PowerShell, a CLI do Azure ou a API REST. Essa operação cria um banco de dados no mesmo servidor que o banco de dados original, mas usa um nome diferente para evitar a substituição do banco de dados original.

  Após a conclusão da restauração, opcionalmente, você poderá excluir o banco de dados original e renomear o banco de dados restaurado para o nome do banco de dados original. Como alternativa, em vez de excluir o banco de dados original, você poderá renomeá-lo e então renomear o banco de dados restaurado para o nome do banco de dados original.

• Restaurar um banco de dados excluído para um momento específico dentro do período de retenção, incluindo a hora de exclusão. O banco de dados excluído só pode ser restaurado no mesmo servidor em que o banco de dados original foi criado. Antes de você excluir um banco de dados, o serviço faz um backup final de log de transações para evitar qualquer perda de dados.

• Restaure um banco de dados para outra região geográfica. A restauração geográfica permite a recuperação de uma interrupção regional quando você não consegue acessar seu banco de dados ou backups na região primária. Ela cria um banco de dados em qualquer servidor existente, em qualquer região do Azure.

  Importante

  A restauração geográfica só está disponível para os bancos de dados configurados com o armazenamento de backup com redundância geográfica. Se você não estiver usando backups replicados geograficamente para um banco de dados, poderá alterar isso configurando a redundância de armazenamento de backup.

• Restaurar um banco de dados de um backup de longo prazo específico de um banco de dados único ou em pool, se o banco de dados tiver sido configurado com uma política LTR. A LTR permite que você restaure uma versão mais antiga do banco de dados usando o portal do Azure, a CLI do Azure ou o Azure PowerShell para atender a uma solicitação de conformidade ou executar uma versão mais antiga do aplicativo. Para obter mais informações, consulte Retenção de longo prazo.

Aviso

Ao restaurar um banco de dados e a redundância de armazenamento de backup de origem estiver configurada como GZRS (armazenamento com redundância de zona geográfica), a configuração de armazenamento de backup de origem é herdada pelo novo banco de dados, caso a configuração de redundância de armazenamento de backup para o banco de dados de destino não seja especificada explicitamente. Isso inclui qualquer operação de restauração, como restauração pontual, cópia de banco de dados, restauração geográfica e restauração de um backup de longo prazo. Durante essa operação, se a região do Azure de destino não der suporte à redundância de armazenamento de backup específica, a operação de restauração falhará com uma mensagem de erro apropriada. Isso pode ser atenuado especificando explicitamente as opções de armazenamento disponíveis para a região.

Backups automáticos em réplicas secundárias

Os backups automáticos agora são obtidos de uma réplica secundária na camada de serviço Comercialmente Crítico. Como os dados são replicados entre os processos do SQL Server em cada node, o serviço de backup usa o backup das réplicas secundárias que não são para leitura. Esse design garante que a réplica primária permaneça dedicada à carga de trabalho main e que a réplica secundária para leitura fique dedicada a cargas de trabalho somente leitura. Na maioria das vezes, os backups automáticos na camada de serviço Comercialmente Crítico são obtidos de uma réplica secundária. Se houver uma falha no backup automático em uma réplica secundária, o serviço de backup usará o backup da réplica primária.

Backups automáticos em réplicas secundárias:

• São habilitados por padrão.
• Estão incluídos sem custo adicional além do preço da camada de serviço.
• Melhoram o desempenho e a previsibilidade para a camada de serviço Comercialmente Crítico.

Observação

• Crie um tíquete de suporte da Microsoft para desabilitar o recurso para sua instância.

Restaurar funcionalidades e recursos

Esta tabela resume as funcionalidades e os recursos de PITR (restauração pontual), restauração geográfica e backups de retenção de longo prazo.

Propriedade de backup	PITR	Restauração geográfica	LTR
Tipos de backup SQL	Completo, diferencial, log.	Copias mais recentes de replicações geográficas de backups de PITR.	Somente os backups completos.
RPO (objetivo de ponto de recuperação)	Dez minutos, com base no tamanho da computação e no volume de atividades do banco de dados.	Até 1 hora, com base na replicação geográfica. 1	Uma semana (ou política do usuário).
RTO (objetivo de tempo de recuperação)	Em geral, a restauração leva menos de 12 horas, mas pode levar mais tempo, dependendo do tamanho e da atividade. Confira também Recuperação.	Em geral, a restauração leva menos de 12 horas, mas pode levar mais tempo, dependendo do tamanho e da atividade. Confira também Recuperação.	Em geral, a restauração leva menos de 12 horas, mas pode levar mais tempo, dependendo do tamanho e da atividade. Confira também Recuperação.
Retenção	7 dias por padrão, configuráveis entre 1 e 35 dias (exceto bancos de dados Básicos, que são configuráveis entre 1 e 7 dias).	Habilitado por padrão; o mesmo que a origem.2	Não habilitado por padrão. A retenção é de até dez anos.
Armazenamento do Azure	Com redundância geográfica por padrão. Opcionalmente, você pode configurar o armazenamento com redundância local ou com redundância de zona.	Disponível quando a redundância de armazenamento de backup PITR é definida como com redundância geográfica. Não disponível quando o armazenamento de backup PITR é com redundância local ou com redundância de zona.	Com redundância geográfica por padrão. Você pode configurar o armazenamento com redundância local ou com redundância de zona.
Configurar backups como imutáveis	Sem suporte	Sem suporte	Sem suporte
Como restaurar um novo banco de dados na mesma região	Com suporte	Compatível	Com suporte
Como restaurar um novo banco de dados em outra região	Sem suporte	Com suporte em qualquer região do Azure	Com suporte em qualquer região do Azure
Como restaurar um novo banco de dados em outra assinatura	Sem suporte	Sem suporte3	Sem suporte3
Restauração por meio do portal do Azure	Sim	Sim	Sim
Restauração por meio do PowerShell	Sim	Sim	Sim
Restauração por meio da CLI do Azure	Sim	Sim	Sim

¹ Para aplicativos comercialmente críticos que exigem grandes bancos de dados e devem garantir a continuidade dos negócios, use grupos de failover.
² Todos os backups PITR são armazenados em armazenamento com redundância geográfica por padrão; portanto, a restauração geográfica é habilitada por padrão.
³ A solução alternativa é restaurar para um novo servidor e usar a movimentação de recursos para mover o servidor para outra assinatura ou usar uma cópia do banco de dados entre assinaturas.

Restaurar um banco de dados de um backup

Para executar uma restauração, confira Restaurar um banco de dados de backups. Explore as operações de configuração de backup e restauração usando os exemplos a seguir.

Operação	Portal do Azure	CLI do Azure	Azure PowerShell
Alterar retenção de backup	Banco de Dados SQL Instância Gerenciada de SQL	Banco de Dados SQL Instância Gerenciada de SQL	Banco de Dados SQL Instância Gerenciada de SQL
Alterar retenção de backup de longo prazo	Banco de Dados SQL Instância Gerenciada de SQL	Banco de Dados SQL Instância Gerenciada de SQL	Banco de Dados SQL Instância Gerenciada de SQL
Restaurar um banco de dados a partir de um momento determinado	Banco de Dados SQL Instância Gerenciada de SQL	Banco de Dados SQL Instância Gerenciada de SQL	Banco de Dados SQL Instância Gerenciada de SQL
Restaurar um banco de dados excluído	Banco de Dados SQL Instância Gerenciada de SQL	Banco de Dados SQL Instância Gerenciada de SQL	Banco de Dados SQL Instância Gerenciada de SQL

Exportar um banco de dados

Os backups automáticos realizados pelo serviço do Azure não estão disponíveis para download ou acesso direto. Eles só podem ser usados para operações de restauração pelo Azure.

Há alternativas para exportar um Banco de Dados SQL do Azure. Quando for necessário exportar um banco de dados para arquivamento ou para transferência para outra plataforma, você pode exportar os dados e o esquema do banco de dados para um arquivo BACPAC. Um arquivo BACPAC é um arquivo ZIP com uma extensão BACPAC que contém os metadados e dados do banco de dados. Um arquivo BACPAC pode ser inserido no Armazenamento de Blobs do Azure ou em uma localização no armazenamento local e depois importado novamente para o Banco de Dados SQL do Azure, a Instância Gerenciada de SQL do Azure ou uma Instância do SQL Server.

Você também pode importar ou exportar um Banco de Dados SQL do Azure usando um link privado ou importar ou exportar um Banco de Dados SQL do Azure sem permitir que os serviços do Azure acessem o servidor.

Agendamento de backup

O primeiro backup completo é agendado imediatamente após a criação ou restauração de um novo banco de dados. Em geral, esse backup é concluído em até 30 minutos, mas pode levar mais tempo quando o banco de dados é grande. Por exemplo, o backup inicial pode levar mais tempo em um banco de dados restaurado ou uma cópia de banco de dados, que normalmente seria maior do que um novo banco de dados.

Após o primeiro backup completo, todos os outros backups são agendados e gerenciados automaticamente. O tempo exato de todos os backups de banco de dados é determinado pelo serviço do Banco de Dados SQL, pois ele equilibra a carga de trabalho geral do sistema. Não é possível alterar o agendamento de trabalhos de backup ou desabilitá-los.

Importante

• Para um banco de dados novo, restaurado ou copiado, a funcionalidade de recuperação pontual fica disponível quando o backup de log de transações inicial que ocorre após o backup completo inicial é criado.
• Os bancos de dados de Hiperescala são protegidos imediatamente após a criação, ao contrário de outros bancos de dados em que o backup inicial leva tempo. A proteção será imediata mesmo se o banco de dados de Hiperescala tiver sido criado com uma grande quantidade de dados por meio de cópia ou restauração. Para saber mais, analise Backups automatizados da Hiperescala.

Consumo de armazenamento de backup

Com a tecnologia de backup e restauração do SQL Server, a restauração de um banco de dados em um momento específico exige uma cadeia de backup ininterrupta. Essa cadeia consiste em um backup completo, opcionalmente, um backup diferencial e um ou mais backups de log de transações.

O Banco de Dados SQL do Azure agendam um backup completo toda semana. Para fornecer o PITR em todo o período de retenção, o sistema precisa armazenar backups adicionais completos, diferenciais e de log de transações por até uma semana mais do que o período de retenção configurado.

Em outras palavras, para qualquer momento específico durante o período de retenção, é preciso haver um backup completo que seja mais antigo do que a hora mais antiga do período de retenção. Também é preciso haver uma cadeia ininterrupta de backups diferenciais e de log de transações desse backup completo até o próximo backup completo.

Os bancos de dados de hiperescala usam um mecanismo de agendamento de backup diferente. Para obter mais informações, confira Agendamento de backup da Hiperescala.

Os backups que não são mais necessários para fornecer a funcionalidade PITR são excluídos automaticamente. Como backups diferenciais e backups de log exigem que um backup completo anterior seja restaurável, todos os três tipos de backup são limpos juntos em conjuntos semanais.

Para todos os bancos de dados, incluindo bancos de dados criptografados com TDE, todos os backups diferenciais e completos são compactados para reduzir a compactação e os custos de armazenamento de backup. A taxa média de compactação de backup é de três a quatro vezes. No entanto, ela pode ser menor ou maior, dependendo da natureza dos dados e se a compactação de dados é usada no banco de dados.

Importante

Para bancos de dados criptografados por TDE, os arquivos de backups de log não são compactados por motivos de desempenho. Os backups de log para bancos de dados não criptografados por TDE são compactados.

O Banco de Dados SQL do Azure calcula o armazenamento de backup total usado como um valor cumulativo. A cada hora, esse valor é relatado para o pipeline de cobrança do Azure. O pipeline é responsável por agregar esse uso por hora para calcular seu consumo no final de cada mês. Depois que o banco de dados é excluído, o consumo diminui à medida que os backups expiram e são excluídos. Depois que todos os backups forem excluídos e o PITR não for mais possível, a cobrança será interrompida.

Importante

Os backups de um banco de dados são mantidos para fornecer o PITR mesmo que o banco de dados tenha sido excluído. Embora a exclusão e a recriação de um banco de dados possam reduzir os custos de armazenamento e de computação, isso pode aumentar os custos de armazenamento de backup. O motivo disso é que o serviço retém os backups para cada banco de dados excluído, sempre que ele é excluído.

Monitorar o consumo

Para bancos de dados vCore no Banco de Dados SQL do Azure, o armazenamento que cada tipo de backup (completo, diferencial e de log) consome é relatado no painel de monitoramento do banco de dados como uma métrica separada. A captura de tela a seguir mostra como monitorar o consumo de armazenamento de backup para um banco de dados individual.

Para obter instruções sobre como monitorar o consumo na Hiperescala, confira Monitorar o consumo do backup da Hiperescala.

Ajuste fino do consumo de armazenamento de backup

O consumo de armazenamento de backup até o tamanho máximo de dados de um banco de dado não é cobrado. O consumo de armazenamento de backup excessivo dependerá da carga de trabalho e máximo tamanho dos bancos de dados individuais. Considere algumas das técnicas de ajuste a seguir para reduzir o consumo de armazenamento de backup:

• Reduza o período de retenção de backup ao mínimo para suas necessidades.
• Evite fazer grandes operações de gravação, como recriações de índice, com mais frequência do que o necessário.
• Para operações de carregamento de dados grandes, considere o uso de índices columnstore clusterizados e seguir as melhores práticas relacionadas a seguir. Considere também a redução do número de índices não clusterizados.
• Na camada de serviço de Uso Geral, o armazenamento de dados provisionado é mais barato do que o preço do armazenamento de backup. Se você estiver sempre com alto excesso de custos de armazenamento de backup, considere aumentar o armazenamento de dados para salvar no armazenamento de backup.
• Use tempdb em vez de tabelas permanentes na lógica do aplicativo para armazenar resultados temporários ou dados transitórios.
• Use o armazenamento de backup com redundância local sempre que possível (por exemplo, ambientes de desenvolvimento/teste).

Retenção de backup

O Banco de Dados SQL do Azure fornece retenção de longo prazo e retenção de curto prazo de backups. A retenção de curto prazo permite o PITR dentro do período de retenção para o banco de dados. A retenção de longo prazo fornece backups para vários requisitos de conformidade.

Retenção de curto prazo

Em todos os bancos de dados novos, restaurados e copiados, o Banco de Dados SQL do Azure retém backups suficientes para permitir a PITR nos últimos sete dias por padrão. O serviço faz backups completos, diferenciais e de log regulares para garantir que os bancos de dados sejam restauráveis em qualquer momento específico dentro do período de retenção definido para o banco de dados.

Os backups diferenciais podem ser configurados para ocorrer uma vez em 12 horas ou uma vez em 24 horas. Uma frequência de backup diferencial de 24 horas pode aumentar o tempo necessário para restaurar o banco de dados em comparação com a frequência de 12 horas. No modelo vCore, a frequência padrão para backups diferenciais é uma vez em 12 horas. No modelo DTU, a frequência padrão é uma vez em 24 horas.

Você pode especificar sua opção de redundância de armazenamento de backup para STR ao criar seu banco de dados e alterá-a posteriormente. Se você alterar sua opção de redundância de backup após a criação do banco de dados, novos backups usarão a nova opção de redundância. As cópias de backup feitas com a opção de redundância de STR anterior não são movidas nem copiadas. Elas são deixadas na conta de armazenamento original até o término do período de retenção, o que pode ser de 1 a 35 dias.

Você pode alterar o período de retenção de backup para cada banco de dados ativo no intervalo de 1 a 35 dias, exceto para os bancos de dados Básicos, que são configuráveis de 1 a 7 dias. Conforme descrito em Consumo de armazenamento de backup, os backups armazenados para habilitar o PITR podem ser mais antigos do que o período de retenção. Caso você precise manter backups por mais tempo do que o período máximo de retenção de curto prazo de 35 dias, habilite a retenção de longo prazo.

Se você excluir um banco de dados, o sistema manterá os backups da mesma forma que um banco de dados online com o período de retenção específico. Não é possível alterar o período de retenção de backup de um banco de dados excluído.

Importante

Se você excluir o servidor, todos os bancos de dados nesse servidor também serão excluídos e não poderão ser recuperados. Você não pode restaurar um servidor excluído. Mas se você tiver configurado a retenção de longo prazo para um banco de dados, os backups LTR não serão excluídos. Em seguida, você poderá usar esses backups para restaurar bancos de dados em um servidor diferente na mesma assinatura para um ponto no tempo em que um backup LTR foi feito. Para saber mais, confira Restaurar um backup de longo prazo.

Retenção de longo prazo

Para o Banco de Dados SQL, você pode configurar backups LTR (retenção de longo prazo) completos por até 10 anos no Armazenamento de Blobs do Azure. Após a política de LTR ser configurada, os backups completos semanais são copiados automaticamente, toda semana, para um contêiner de armazenamento diferente.

Para atender a vários requisitos de conformidade, é possível selecionar diferentes períodos de retenção para backups completos semanais, mensais e/ou anuais. A frequência depende da política. Por exemplo, a configuração W=0, M=1 criará uma cópia LTR mensalmente. Para obter mais informações sobre a LTR, confira Retenção de longo prazo.

Atualizar a redundância de armazenamento de backup para um banco de dados existente aplica a alteração apenas aos backups subsequentes feitos no futuro e não para backups existentes. Todos os backups LTR existentes para o banco de dados continuarão a residir no BLOB de armazenamento existente. Novos backups serão replicados com base na redundância de armazenamento de backup configurada.

O consumo de armazenamento depende da frequência selecionada e dos períodos de retenção de backups LTR. Você pode usar a Calculadora de preços de LTR para estimar o custo do armazenamento de LTR.

Ao restaurar um banco de dados de Hiperescala por meio de uma cópia de segurança LTR, a propriedade de escala de leitura é desabilitada. Para habilitar a escala de leitura no banco de dados restaurado, atualize o banco de dados depois que ele for criado. Você precisa especificar o objetivo do nível de serviço ao restaurar por meio de um backup LTR.

A retenção de longo prazo pode ser habilitada para bancos de dados de Hiperescala criados ou migrados de outras camadas de serviço. Se você tentar habilitar o LTR para um banco de dados de hiperescala ainda sem suporte, receberá o seguinte erro: "Ocorreu um erro ao habilitar a retenção de backup de longo prazo para este banco de dados. Entre em contato com o suporte da Microsoft para habilitar a retenção de backup de longo prazo.” Nesse caso, entre em contato com o suporte da Microsoft e crie um tíquete de suporte para resolver o problema.

Custos de armazenamento backup

O preço do armazenamento de backup varia e depende de seu modelo de compra (DTU ou vCore), da opção de redundância de armazenamento de backup escolhida e da região. O armazenamento de backup é cobrado com base em gigabytes consumidos por mês, na mesma taxa para todos os backups.

A redundância de armazenamento de backup afeta os custos de backup da seguinte maneira:

• Locally redundant price = published price
• Zone-redundant price = published price x 1.25
• Geo-redundant price = published price x 2

Para saber mais sobre preços, confira a página Preços do Banco de Dados SQL do Azure.

Observação

A fatura do Azure mostra apenas o consumo em excesso do armazenamento de backup, não o consumo inteiro. Por exemplo, em um cenário hipotético, se você tiver provisionado 4 TB de armazenamento de dados, receberá 4 TB de espaço livre de armazenamento de backup. Se você usar um total de 5,8 TB de espaço de armazenamento de backup, a fatura do Azure só mostrará 1,8 TB, pois você só receberá a cobrança pelo armazenamento de backup excedente usado.

Modelo de CPU

No modelo DTU, para bancos de dados e pools elásticos, não há custo adicional para armazenamento de backup PITR para retenção padrão de 7 dias ou mais. O preço do armazenamento de backup PITR faz parte do preço do banco de dados ou pool.

Importante

No modelo DTU, bancos de dados e pools elásticos são cobrados pelo armazenamento de backup LTR com base no armazenamento real consumido pelos backups LTR.

Modelo vCore

O Banco de Dados SQL do Azure calcula seu armazenamento de backup faturável total como um valor cumulativo em todos os arquivos de backup. A cada hora, esse valor é relatado para o pipeline de cobrança do Azure. O pipeline agrega esse uso por hora para obter seu consumo de armazenamento de backup no final de cada mês.

Se um banco de dados for excluído, o consumo de armazenamento de backup diminuirá gradualmente conforme os backups mais antigos expirarem e serão excluídos. Como backups diferenciais e backups de log exigem que um backup completo anterior seja restaurável, todos os três tipos de backup são limpos juntos em conjuntos semanais. Depois que todos os backups forem excluídos, a cobrança será interrompida.

O custo de armazenamento de backup é calculado de forma diferente para bancos de dados da Hiperescala. Para obter mais informações, confira Custos de armazenamento de backup da Hiperescala.

Para bancos de dados individuais, um valor de armazenamento de backup mínimo equivalente a 100 por cento do tamanho máximo do armazenamento de dados do banco de dados é fornecido sem custo adicional. A equação a seguir é usada para calcular o uso do armazenamento de backup total faturável:

Total billable backup storage size = (size of full backups + size of differential backups + size of log backups) – maximum data storage

Para pools elásticos, uma quantidade de armazenamento de backup igual a 100% do armazenamento de dados máximo para o tamanho do armazenamento do pool é fornecida sem custos. Para bancos de dados em pool, o tamanho total de armazenamento de backup faturável é agregado no nível do pool e é calculado da seguinte maneira:

Total billable backup storage size = (total size of all full backups + total size of all differential backups + total size of all log backups) - maximum pool data storage

O armazenamento total de backup faturável, se houver, é cobrado em gigabytes por mês de acordo com a taxa da redundância de armazenamento de backup que você usou. Esse consumo de armazenamento de backup depende da carga de trabalho e do tamanho de bancos de dados individuais, pools elásticos e instâncias gerenciadas. Bancos de dados muito modificados têm backups diferenciais e de log maiores, pois o tamanho desses backups é proporcional à quantidade de dados alterados. Portanto, esses bancos de dados têm preços mais altos de backup.

Como um exemplo simplificado, suponha que um banco de dados tenha acumulado 744 GB de armazenamento de backup e que esse valor permaneça constante durante um mês inteiro, pois o banco de dados está completamente ocioso. Para converter esse consumo de armazenamento cumulativo no uso por hora, divida-o por 744 (31 dias por mês x 24 horas por dia). O Banco de Dados SQL reporta ao pipeline de cobrança do Azure que o banco de dados consumiu 1 GB de backup de PITR a cada hora, a uma taxa constante. A cobrança do Azure agrega esse consumo e mostrará um uso de 744 GB para o mês inteiro. O custo é baseado na taxa de gigabytes por mês na sua região.

Confira outro exemplo. Suponha que o mesmo banco de dados ocioso tenha sua retenção aumentada de 7 dias para 14 dias no meio do mês. Esse aumento resulta na duplicação total do armazenamento de backup para 1.488 GB. O Banco de Dados SQL relataria 1 GB de uso para as horas de 1 a 372 (a primeira metade do mês). Ele relataria o uso como 2 GB para as horas de 373 a 744 (a segunda metade do mês). Esse uso será agregado a uma fatura final de 1.116 GB por mês.

Os cenários de cobrança de backup reais são mais complexos. Como a taxa de alterações no banco de dados depende da carga de trabalho e é variável ao longo do tempo, o tamanho de cada backup diferencial e de log varia também. O consumo por hora do armazenamento de backup flutua de maneira correspondente.

Cada backup diferencial também contém todas as alterações feitas no banco de dados desde o último backup completo. Portanto, o tamanho total de todos os backups diferenciais aumenta gradualmente ao longo de uma semana. Em seguida, ele cai bruscamente depois que um conjunto mais antigo de backups completos, diferenciais e de log envelhece.

Por exemplo, suponha que uma atividade de gravação pesada, como uma recriação de índice, seja executada logo após a conclusão de um backup completo. As modificações feitas pela recompilação de índice serão incluídas:

• Nos backups de log de transações feitos durante a recompilação.
• No próximo backup diferencial.
• Em cada backup diferencial feito até o próximo backup completo.

Para o último cenário em bancos de dados maiores, uma otimização no serviço cria um backup completo em vez de um backup diferencial, caso um backup diferencial seja, de outro modo, excessivamente grande. Isso reduz o tamanho de todos os backups diferenciais até o backup completo a seguir.

Você pode monitorar o consumo de armazenamento de backup total para cada tipo de backup (completo, diferencial, log de transações) ao longo do tempo, conforme descrito em Monitorar o consumo.

Monitorar custos

Para entender os custos de armazenamento de backup, acesse Gerenciamento de Custos e Cobrança no portal do Azure. Selecione Gerenciamento de Custos e Análise de custo. Escolha a assinatura desejada em Escopo e filtre o conteúdo pelo período e pelo serviço de seu interesse, desta forma:

1. Adicione um filtro para o Nome do serviço.

2. Na lista suspensa, selecione o banco de dados sql para um banco de dados individual ou um pool de banco de dados elástico.

3. Adicione outro filtro para a Subcategoria do medidor.

4. Para monitorar os custos de backup PITR, na lista suspensa, selecione armazenamento de backup PITR de pool único/elástico para um único banco de dados ou um pool de banco de dados elástico. Os medidores só serão exibidos se houver algum consumo de armazenamento de backup.

   Para monitorar os custos de backup PITR, na lista suspensa, selecione armazenamento de backup ltr para um único banco de dados ou um pool de banco de dados elástico. Os medidores só serão exibidos se houver algum consumo de armazenamento de backup.

As subcategorias Armazenamento e Computação também podem ser de interesse, mas não estão associadas aos custos de armazenamento de backup.

Importante

Os medidores só ficam visíveis para os contadores que estão sendo usados no momento. Se um contador não estiver disponível, será provável que a categoria não esteja sendo usada no momento. Por exemplo, os contadores de armazenamento não ficarão visíveis para os recursos que não estão consumindo armazenamento. Se não houver nenhum consumo de armazenamento de backup PITR ou LTR, esses medidores não ficarão visíveis.

Para obter mais informações, confira Gerenciamento de custos do Banco de dados SQL do Azure.

Backups criptografados

Quando o banco de dados é criptografado com TDE, os backups são criptografados automaticamente em repouso, incluindo os backups de LTR. Todos os novos bancos de dados no Azure SQL são configurados com TDE habilitado por padrão. Para obter mais informações sobre a TDE, confira Criptografia de dados transparente com o Banco de Dados SQL.

Integridade do backup

Continuamente, a equipe de engenharia do SQL do Azure testa automaticamente a restauração de backups de banco de dados automatizados. Na restauração pontual, os bancos de dados também recebem verificações de integridade do DBCC CHECKDB.

Os problemas encontrados durante a verificação de integridade resultarão em um alerta para a equipe de engenharia. Para obter mais informações, confira Integridade de dados no Banco de Dados SQL.

Todos os backups de banco de dados são obtidos com a opção CHECKSUM para fornecer integridade de backup adicional.

Conformidade

Quando você migra seu banco de dados de uma camada de serviço baseada em DTU para uma camada de serviço baseada em vCore, a retenção de PITR é preservada para garantir que a política de recuperação de dados do aplicativo não seja comprometida. Se a retenção padrão não atender aos seus requisitos de conformidade, você poderá alterar o período de retenção de PITR. Para obter mais informações, consulte Alterar o período de retenção de backup de PITR.

Observação

O artigo Alterar configurações do backup automatizado mostra as etapas de como excluir dados pessoais do dispositivo ou serviço e pode ser usado para dar suporte às suas obrigações de acordo com o GDPR. Para obter informações gerais sobre o GDPR, confira a seção GDPR da Central de Confiabilidade da Microsoft e a seção GDPR do Portal de Confiança do Serviço.

Usar Azure Policy para aplicar a redundância de armazenamento de backup

Se você tiver requisitos de residência de dados que exijam que todos os dados sejam mantidos em uma só região do Azure, o ideal será impor backups com redundância de zona ou com redundância local para o banco de dados SQL usando o Azure Policy.

O Azure Policy é um serviço que você pode usar para criar, atribuir e gerenciar políticas que aplicam regras aos recursos do Azure. O Azure Policy ajuda você a manter esses recursos em conformidade com seus padrões corporativos e com os contratos de nível de serviço. Para saber mais, confira Visão geral do Azure Policy.

Políticas internas de redundância de armazenamento de backup

Para impor os requisitos de residência de dados na organização, atribua políticas a uma assinatura usando o portal do Azure ou o Azure PowerShell.

Por exemplo, se você habilitar a política “O DB SQL do Azure deve evitar o uso de backup GRS”, os bancos de dados não poderão ser criados com o armazenamento padrão como armazenamento globalmente redundante, e os usuários serão impedidos de usar o GRS com a mensagem de erro “A configuração do tipo de conta de armazenamento de backup para ‘Standard_RAGRS’ falhou durante a criação ou atualização do banco de dados”.

Para ver a lista completa de definições de política interna do Banco de Dados SQL, confira a referência de política.

Importante

As políticas do Azure não são impostas quando um banco de dados é criado por meio do T-SQL. Para especificar a residência de dados ao criar um banco de dados usando o T-SQL, use LOCAL ou ZONE como entrada para o parâmetro BACKUP_STORAGE_REDUNDANCY na instrução CREATE DATABASE.

Conteúdo relacionado

• Para saber mais sobre as outras soluções de continuidade dos negócios do Banco de Dados SQL, confira Visão geral da continuidade dos negócios.
• Para alterar as configurações de backup, confira Alterar configurações.
• Para restaurar um backup, confira Recuperar usando backups ou Restaurar um banco de dados para um ponto no tempo usando o PowerShell.
• Para obter informações sobre como configurar, gerenciar e restaurar a retenção de longo prazo de backups automatizados no Armazenamento de Blobs do Azure, confira Gerenciar a retenção de backup de longo prazo.
• Para a Instância Gerenciada de SQL do Azure, confira Backups automatizados para a Instância Gerenciada de SQL.