Backups automatizados no Banco de Dados SQL do Azure

Aplica-se a:Banco de Dados 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 tradicional de backup SQL Server, bancos de dados maiores têm longos tempos de backup e restauração. Ao usar snapshots, o Hyperscale oferece backup instantâneo e capacidade de 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 horas ou 24 horas.
• Backups de log de transações a cada dez minutos, aproximadamente.

A frequência exata dos backups de logs de transação depende do tamanho do processamento e da quantidade de atividade do banco de dados. Quando você restaura um banco de dados, o Banco de Dados SQL do Azure determina quais backups de logs completos, diferenciais e de transações devem 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 múltiplas cópias dos seus dados para que ele esteja protegido 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. Você pode substituir essas configurações. 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 tem menor custo e é apropriado para ambientes de pré-produção que não exigem armazenamento replicado por zona ou geograficamente.
• 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 Ambiente de carga de trabalho também altera a configuração inicial de computação, embora você possa substituir essa configuração. 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 seus backups permaneçam na mesma região onde seu banco de dados é implantado, altere a redundância do armazenamento geo-redundante padrão para outros tipos de armazenamento que mantenham seus dados dentro da região. A redundância de armazenamento de backup configurada é aplicada tanto a backups de retenção de curto prazo (STR) quanto a backups de retenção de longo prazo (LTR). Para saber mais sobre redundância de armazenamento, confira Redundância de dados.

Você pode configurar a redundância do armazenamento de backup ao criar seu banco de dados, e pode atualizá-lo depois. As mudanças que você faz em um banco de dados existente se aplicam apenas a 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 é recomendado para aplicações que exigem resiliência a quedas regionais ou garantia de alta durabilidade dos 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 seus dados de forma assíncrona três vezes para um único 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.

  

• Armazenamento Redundante de Zona Geográfica (GZRS): O Armazenamento Redundante de Zona Geográfica (GZRS) combina a alta disponibilidade fornecida pela redundância entre Zonas de Disponibilidade (ZRS) com proteção contra interrupções regionais fornecidas pela Replicação Geográfica (GRS). No GZRS, o Azure copia seus backups de forma síncrona entre três zonas de disponibilidade do Azure na região primária, e assíncronamente três vezes para um único local físico na região secundária pareada.

  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 assíncronas que foram feitas 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:

  

Uso do backup

Use 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. Você só pode restaurar o banco de dados deletado no mesmo servidor onde criou o banco original. Antes de excluir um banco de dados, o Banco de Dados SQL do Azure faz um backup final do 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 ajuda você a se recuperar de uma queda regional quando não consegue acessar seu banco de dados ou backups na região principal. 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 está usando backups geo-replicados para um banco de dados, pode alterar essa configuração configurando a redundância do armazenamento de backup.

• Restaure um banco de dados a partir de um backup específico de longo prazo de um único banco de dados ou de um banco de dados agrupado, se o banco de dados estiver configurado com uma política de 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.

Backups automáticos em réplicas secundárias

O nível de serviço Business Critical recebe backups automáticos de uma réplica secundária. Como os dados são replicados entre os processos do SQL Server em cada nó, o serviço de backup realiza o backup a partir das réplicas secundárias não legíveis. Esse design garante que a réplica primária permaneça dedicada à carga de trabalho principal e que a réplica secundária para leitura fique dedicada a cargas de trabalho apenas 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 um backup automático falhar em uma réplica secundária, o serviço de backup pega o backup da réplica primária.

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

• São habilitados por padrão.
• São incluídos sem custo adicional além do preço do nível de serviço.
• Traga melhor desempenho e previsibilidade para a camada de serviço Crítico para Negócios.

Restaurar funcionalidades e recursos

Esta tabela resume as capacidades e características de restauração pontual (PITR), restauração geográfica e retenção de longo prazo.

Para obter informações sobre os tempos de recuperação, consulte RTO e RPO.

¹ 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 mais informações sobre restauração de um banco de dados, veja Restaurar um banco de dados a partir de backups. Para explorar a configuração de backup e as operações de restauração, use os exemplos a seguir.

Exportar um banco de dados

Você não pode baixar ou acessar diretamente backups automáticos feitos pelo serviço Azure. O Azure usa esses backups apenas para operações de restauração.

Para exportar um Banco de Dados SQL do Azure, considere outras alternativas.

• Quando precisar exportar um banco de dados para arquivamento ou para migrar para outra plataforma, exporte o esquema e os dados 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. Você pode armazenar um arquivo BACPAC no armazenamento Azure Blob ou em armazenamento local em um local local. Depois, você pode importar de volta para o Banco de Dados SQL do Azure, 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 logo após você criar ou restaurar 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 demorar mais em um banco de dados restaurado ou em uma cópia do banco de dados.

Após o primeiro backup completo, o Azure automaticamente agenda e gerencia todos os backups seguintes. O serviço de Banco de Dados SQL determina o momento exato de todos os backups do banco de dados enquanto equilibra a carga de trabalho geral do sistema. Não é possível alterar o agendamento de trabalhos de backup ou desabilitá-los.

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 agenda um backup completo toda semana. Para fornecer PITR dentro de todo o período de retenção, o Azure deve armazenar backups adicionais completos, diferenciais e de logs de transações por até uma semana a mais do que o período de retenção configurado.

Em outras palavras, para qualquer ponto no tempo durante o período de retenção, deve haver um backup completo que seja mais antigo que o tempo mais antigo do período de retenção. Também deve 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.

O Azure elimina automaticamente backups que não são mais necessários para fornecer funcionalidade PIR. Como os backups diferenciais e de log exigem um backup completo prévio para que possam ser restaurados, o Azure remove os três tipos de backup juntos em conjuntos semanais.

Para todos os bancos de dados, incluindo bancos criptografados por TDE, o Azure comprime todos os backups completos e diferenciais para reduzir a compressão e custos de armazenamento de backup. A taxa média de compressã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.

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

Monitorar o consumo

Para bancos de dados vCore no Banco de Dados SQL do Azure, o painel de monitoramento do banco de dados relata o armazenamento que cada tipo de backup (full, diferencial e log) consome 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

Você não é cobrado pelo consumo de armazenamento de backup até o tamanho máximo de dados de um banco de dados. Para reduzir o consumo de armazenamento de backup, considere algumas das seguintes técnicas de ajuste:

• Reduza o período de retenção de backup ao mínimo para suas necessidades.
• Evite fazer grandes operações de gravação, como reconstruçõ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ê tem custos excessivos de armazenamento de backup continuamente altos, considere aumentar o armazenamento de dados para economizar 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

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

Você pode configurar backups diferenciais para ocorrerem uma vez a cada 12 horas ou uma vez a cada 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 a opção de redundância de armazenamento de backup para STR quando criar seu banco de dados, e depois mudá-la. Se você mudar a opção de redundância de backup em um banco de dados existente, novos backups usam a nova opção de redundância. O Azure não move nem copia cópias de backup feitas com a opção anterior de redundância de curto prazo. O Azure os mantém na conta de armazenamento original até o término do período de retençã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 Azure mantém backups da mesma forma que um banco de dados online com seu período específico de retenção. Não é possível alterar o período de retenção de backup de um banco de dados excluído.

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. Depois que você configura a política LTR, o Azure copia automaticamente backups completos para um container de armazenamento diferente semanalmente.

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

A atualização da redundância do armazenamento de backup de um banco de dados existente aplica a alteração apenas aos backups realizados futuramente, e não aos backups existentes. Todos os backups LTR existentes para o banco de dados continuarão a residir no blob de armazenamento já 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. Use a calculadora de preços de LTR para estimar o custo do armazenamento de LTR.

Ao restaurar um banco de dados de Hiperescala a partir de um backup 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.

Você pode habilitar a retenção de longo prazo para bancos de dados Hyperscale criados ou migrados de outros níveis 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. Por favor, entre em contato com o suporte da Microsoft para permitir a retenção de backup a longo prazo." Nesse caso, entre em contato com o suporte da Microsoft e crie um chamado de suporte para resolver.

Custos de armazenamento de 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. Você paga pelo armazenamento de backup com base em gigabytes consumidos por mês, na mesma taxa para todos os backups.

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

Modelo de DTU

No modelo DTU, para bancos de dados e pools elásticos não há custo extra pelo armazenamento de backup PITR para retenção padrão de sete dias ou mais. O preço do armazenamento de backup do PITR está incluído no preço do banco de dados ou do pool.

No modelo DTU, você paga pelo armazenamento de backup LTR para bancos de dados e pools elásticos com base no armazenamento real consumido pelos backups LTR.

Modelo vCore

O Banco de Dados SQL do Azure calcula o total de armazenamento de backup sujeito a cobrança de forma cumulativa, considerando todos os arquivos de backup. A cada hora, o Azure envia esse valor para o pipeline de faturamento. O pipeline agrega esse uso por hora para determinar seu consumo de armazenamento de backup ao final de cada mês.

Se você deletar um banco de dados, o consumo de armazenamento de backup diminui gradualmente à medida que backups antigos envelhecem e são apagados. Como os backups diferenciais e de log exigem um backup completo prévio para que possam ser restaurados, o Azure remove os três tipos de backup juntos em conjuntos semanais. Depois que todos os backups forem excluídos, a cobrança será interrompida.

Bancos de dados hiperescaláveis usam um método diferente para calcular custos de armazenamento de backup. Para obter mais informações, confira Custos de armazenamento de backup Hyperscale.

Para bancos de dados individuais, você recebe um valor de armazenamento de backup igual ao tamanho máximo de armazenamento de dados do banco de dados, sem custo adicional. A equação a seguir calcula o uso total de armazenamento de backup 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, você recebe uma quantidade de armazenamento de backup igual ao máximo de armazenamento de dados para o tamanho do pool sem custo extra. 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

Você paga pelo armazenamento total faturável de backup, se houver, em gigabytes por mês de acordo com a redundância de armazenamento de backup. 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 exemplo simplificado, suponha que um banco de dados acumule 744 GB de armazenamento de backup e que essa quantidade permaneça constante durante todo um mês porque 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. O faturamento do Azure agrega esse consumo e mostra um uso de 744 GB para todo o mês. 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 reporta 1 GB de uso das horas 1 a 372 (a primeira metade do mês). Ele informa o uso como 2 GB nas horas 373 a 744 (segunda metade do mês). Esse consumo soma 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 mudanças 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 também varia. 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. Depois, ele cai drasticamente depois que um conjunto mais antigo de backups completos, diferenciais e de log expira.

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 que a reconstrução do índice faz estão incluídas:

• No log de transações, backups feitos durante a reconstrução.
• No próximo backup diferencial.
• Em cada backup diferencial realizado até que ocorra o próximo backup completo.

No último cenário, em bancos de dados maiores, uma otimização no Azure cria um backup completo em vez de um backup diferencial se um backup diferencial seria excessivamente grande caso contrário. Essa otimização reduz o tamanho de todos os backups diferenciais até o backup completo seguinte.

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 aparecem somente se houver 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 aparecem somente se houver 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.

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

Backups criptografados

Se você criptografar seu banco de dados usando TDE, os backups são automaticamente criptografados em repouso, incluindo backups LTR. Todos os novos bancos de dados no SQL do Azure 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

Banco de Dados SQL do Azure lida automaticamente com certos tipos de corrupção de dados usando técnicas integradas quando necessário, sem perda de dados. No Banco de Dados SQL do Azure, o SQL Mecanismo de Banco de Dados realiza a verificação de páginas durante backups gerenciados por serviços e em cada operação de restauração. Os problemas encontrados durante a verificação de integridade resultarão em um alerta para a equipe de engenharia.

Como uma camada extra de proteção, você pode testar a restauração de backup e realizar verificações de integridade. Para mais informações, veja Integridade de dados no Banco de Dados SQL do Azure.

Todos os backups de banco de dados usam a CHECKSUM opção de fornecer integridade extra de backup.

Proteção de backup

As assinaturas do Azure pertencentes à Microsoft gerenciam backups do Banco de Dados SQL do Azure usando contas internas seguras do Armazenamento do Azure. Você não pode acessar esses backups externamente, então eles oferecem forte isolamento e proteção dos dados. Dentro da Microsoft, apenas os serviços de backend podem acessar, criar, copiar ou restaurar esses backups. Os engenheiros da Microsoft, incluindo desenvolvedores, não têm acesso permanente. Para minimizar a exposição e maximizar a segurança, a Microsoft só pode obter acesso just-In-Time (JIT) sob controles de auditoria rigorosos quando absolutamente necessário para solucionar problemas específicos do cliente.

Backups são automaticamente excluídos após o término do período de retenção.

Conformidade por meio da retenção de backup

Se a retenção padrão não atender aos seus requisitos de conformidade, altere o período de retenção do PITR. Para obter mais informações, consulte Alterar o período de retenção de backup de PITR.

Quando você migra seu banco de dados de um nível de serviço baseado em DTU para um nível de serviço baseado em vCore, a migração preserva a retenção do PITR para garantir que a política de recuperação de dados da sua aplicação não seja comprometida.

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

Se você tem requisitos de residência de dados que exigem que você mantenha todos os seus dados em uma única região Azure, pode impor backups redundantes por zona ou localmente redundantes para seu 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 acordos 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 requisitos de residência de dados em nível organizacional, atribua políticas a uma assinatura usando o portal Azure ou Azure PowerShell.

Por exemplo, se você ativar a política "SQL do Azure DB deve evitar usar backup GRS", os usuários não podem criar bancos de dados com o armazenamento padrão como armazenamento globalmente redundante. A política impede que usuários usem GRS e retorna a mensagem de erro "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 uma lista completa de definições de políticas integradas para o Banco de Dados SQL, veja a referência de política.

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.