Compartilhar via

Backups automatizados na Instância Gerenciada de SQL do Azure

Aplica-se a:Instância Gerenciada de SQL do Azure

Este artigo descreve o recurso de backup automatizado da Instância Gerenciada de SQL do Azure.

Para alterar as configurações de backup, consulte Alterar as configurações de backup automatizado para a Instância Gerenciada de SQL do Azure. Para restaurar um backup, consulte Restaurar um banco de dados de um backup na Instância Gerenciada de SQL do Azure.

O que são backups automatizados 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. Com a Instância Gerenciada de SQL do Azure, os backups do mecanismo de banco de dados do SQL Server são gerenciados automaticamente pela Microsoft e armazenados em contas de armazenamento do Azure gerenciadas pela Microsoft.

Use esses backups para restaurar o banco de dados para um ponto específico no tempo dentro do período de retenção configurado de até 35 dias. No entanto, se as suas regras de proteção de dados exigirem que os backups fiquem disponíveis por um tempo estendido (até dez anos), configure políticas de LTR (retenção de longo prazo) para cada banco de dados.

Frequência de backup

A Instância Gerenciada de SQL do Azure cria:

A frequência dos backups de logs de transações depende do tamanho dos recursos de computação e da quantidade de atividade do banco de dados. Os logs de transações são feitos aproximadamente a cada 10 minutos, mas podem variar. Quando você restaura um banco de dados, o serviço determina quais backups completos, diferenciais e de log de transações precisam ser restaurados na respectiva ordem.

Cuidado

Os backups completos automáticos são iniciados uma vez por semana com base em um agendamento determinado pela Microsoft. Os backups iniciados pelo usuário têm prioridade sobre os backups completos automáticos, portanto, um backup somente de cópia de longa duração pode afetar o tempo do próximo backup completo automático.

Um backup do log final é feito sempre que um banco de dados ou instância gerenciada por SQL é excluído.

Os bancos de dados do sistema são automaticamente armazenados em backup (excluindo o banco de dados físico master), mas esses backups não estão atualmente registrados em msdb.

Redundância do armazenamento de backup

Por padrão, a Instância Gerenciada de SQL do Azure armazena os 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. Também permite que você restaure sua instância em outra região, em caso de desastre.

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.

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. 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 sua instância, e pode atualizá-la posteriormente no nível da instância. As alterações feitas em uma instância existente só se aplicam aos backups futuros. Depois que você atualizar a redundância de armazenamento de backup de uma instância existente, poderá levar até 24 horas para que as alterações sejam aplicadas. As alterações feitas na redundância de armazenamento de backup só se aplicam aos backups de curto prazo. As políticas de retenção de longo prazo, ao serem criadas, herdam a opção de redundância dos backups de curto prazo. A opção de redundância persiste para backups de longo prazo, mesmo que a opção de redundância para backups de curto prazo seja alterada posteriormente.

Observação

Alterar a redundância de backup é uma operação de gerenciamento de atualizações que inicia um failover.

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 replicação menos cara, mas não a recomendamos para os aplicativos que exigem alta disponibilidade ou durabilidade.

    Diagrama que mostra a opção de armazenamento com redundância local (LRS).

  • 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. Atualmente, está disponível em algumas regiões.

    Diagrama que mostra a opção de ZRS (armazenamento com redundância de zona).

  • 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 três vezes 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 dentro de uma única zona de disponibilidade.
    • Três cópias síncronas na região pareada dentro de uma única zona de disponibilidade que foram copiadas da região primária para a região secundária de forma assíncrona.

    Diagrama que mostra a opção de GRS (armazenamento com redundância geográfica).

  • GZRS (armazenamento com redundância de zona geográfica): combina a alta disponibilidade fornecida pela redundância entre zonas de disponibilidade com a proteção contra interrupções regionais fornecida pela replicação geográfica. Os dados de uma conta de GZRS são copiados em três zonas de disponibilidade do Azure na região primária. Os dados também são replicados para uma região geográfica secundária para proteção contra desastres regionais. Nessa região, você também tem três cópias síncronas em uma única zona de disponibilidade que foram feitas da região primária para a região secundária de maneira assíncrona.

    Diagrama mostrando a opção de GZRS (armazenamento com redundância de zona geográfica).

Aviso

  • Restauração geográfica é desabilitado assim que um banco de dados é atualizado para usar armazenamento redundante localmente ou redundante por zona.
  • Todos os diagramas de redundância de armazenamento mostram as regiões com várias zonas de disponibilidade (multi-az). No entanto, há algumas regiões que fornecem apenas uma única zona de disponibilidade e não dão suporte a ZRS ou GZRS.

Uso do backup

Use esses backups para:

  • Restaurar um banco de dados existente em um momento específico no passado 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 na mesma instância do banco de dados original ou em uma instância diferente na mesma assinatura e região. Ela usa um nome diferente para evitar a substituição do banco de dados original. Use também o portal do Azure para restaurar o backup de banco de dados pontual para uma instância em uma assinatura diferente da instância de origem.

    Depois que a restauração é concluída, você pode excluir o banco de dados original. Como alternativa, você pode renomear o banco de dados original e renomear o banco de dados restaurado com 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ê pode restaurar o banco de dados excluído na mesma instância gerenciada em que o backup foi feito ou em outra instância na mesma assinatura ou em uma assinatura diferente da instância de origem. 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 um desastre geográfico 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 instância gerenciada 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 de um banco de dados, se o banco de dados tem uma política de LTR configurada. 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 antiga do aplicativo. Para mais informações, consulte Backups de retenção de longo prazo - Banco de Dados SQL do Azure e Instância Gerenciada de SQL do Azure.

Restaurar funcionalidades e recursos

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

Propriedades de Backup PITR Restauração geográfica LTR
Tipos de backup SQL Backups completos, diferenciais e de log de transações. Cópias replicadas de backups PITR. Somente backups completos.
RPO (objetivo de ponto de recuperação) Aproximadamente 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 1 a 35 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. Se preferir, você pode configurar o armazenamento com redundância de zona ou local. Disponível quando a redundância de armazenamento de backup PITR é definida como geo-redundante. 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 de zona ou com redundância local.
Configurar backups como imutáveis Sem suporte Sem suporte Sem suporte
Política de atualização3 Deve corresponder ou melhorar Deve corresponder ou melhorar Deve corresponder ou melhorar
Como restaurar um novo banco de dados na mesma região Com suporte Com suporte 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 Com suporte Não suportado 4 Não suportado 4
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

1 Para aplicativos críticos para os negócios que exigem grandes bancos de dados e devem garantir a continuidade dos negócios, consulte grupos de failover.
2 Todos os backups de PITR são mantidos em um armazenamento com redundância geográfica por padrão. Portanto, a restauração geográfica está habilitada por padrão.
3 Os backups de banco de dados obtidos de instâncias configuradas com a política de atualização do SQL Server 2022 podem ser restaurados para instâncias configuradas com a política de atualização do SQL Server 2022 ou Always-up-to-date. Os backups de banco de dados obtidos de instâncias configuradas com a política de atualização sempre atualizada só podem ser restaurados para instâncias também configuradas com a política de atualização Sempre atualizado.
4 A solução alternativa é restaurá-lo para um novo servidor e usar a movimentação de recursos para mover o servidor para outra assinatura.

Restaurar um banco de dados de um backup

Para executar uma restauração, consulte Restaurar um banco de dados de um backup na Instância Gerenciada de SQL do Azure. Experimente 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 Bancos de dados SQL / Instância Gerenciada de SQL Bancos de dados SQL / Instância Gerenciada de SQL Bancos de dados SQL / Instância Gerenciada de SQL
Alterar retenção de backup de longo prazo Bancos de dados SQL / Instância Gerenciada de SQL Bancos de dados SQL / Instância Gerenciada de SQL Bancos de dados SQL / Instância Gerenciada de SQL
Restaurar um banco de dados a partir de um momento determinado Bancos de dados SQL / Instância Gerenciada de SQL Bancos de dados SQL / Instância Gerenciada de SQL Bancos de dados SQL / Instância Gerenciada de SQL
Restaurar um banco de dados excluído Bancos de dados SQL / Instância Gerenciada de SQL Bancos de dados SQL / Instância Gerenciada de SQL Bancos de dados SQL / Instância Gerenciada de SQL
Restaurar um banco de dados do Armazenamento de Blobs do Azure Instância Gerenciada de SQL

Agendamento de backups automáticos

A Instância Gerenciada de SQL do Azure gerencia backups automaticamente criando backups completos, diferenciais e de log de transações. Esse processo é regido por um agendamento interno.

Backup inicial

Imediatamente depois que um banco de dados é criado, restaurado ou passa por alterações de redundância de backup, o primeiro backup completo é iniciado. Esse backup normalmente é concluído dentro de 30 minutos, embora possa levar mais tempo. A duração do backup inicial para bancos de dados restaurados varia e depende do tamanho do banco de dados. Bancos de dados restaurados maiores ou cópias de banco de dados podem exigir mais tempo para o backup inicial.

Importante

O primeiro backup completo de um novo banco de dados tem prioridade sobre outros backups de banco de dados, portanto, é o primeiro backup feito durante a primeira janela de backup completo. Se a janela de backup completa já estiver ativa e outros bancos de dados estiverem sendo armazenados em backup, o primeiro backup completo do novo banco de dados será feito imediatamente após a conclusão do backup completo de outro banco de dados.

Backups completos agendados

  • Agendamento semanal: o sistema define uma janela de backup completo semanal para a instância inteira.
  • Janela de backup completo: um período designado no qual os backups completos são executados. Embora o sistema tenha como objetivo concluir backups completos nessa janela, se necessário, o backup poderá continuar além do tempo agendado até que ele seja concluído.
  • Agendamento adaptável: o algoritmo de backup avalia o impacto da janela de backup na carga de trabalho aproximadamente uma vez por semana, utilizando as informações de uso da CPU e a produtividade de E/S como indicadores. Dependendo da carga de trabalho da semana anterior, a janela de backup completa pode ser ajustada.
  • Configuração do Usuário: os usuários não podem modificar ou desabilitar o agendamento de backup.

Importante

Para um banco de dados novo, restaurado ou copiado, a funcionalidade de recuperação pontual (PITR) fica disponível depois que o backup de log de transações inicial é concluído após o backup completo inicial.

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.

Os agendamentos de backup da Instância Gerenciada de SQL do Azure incluem 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 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 backups que não são mais necessários para fornecer a funcionalidade PITR são excluídos automaticamente. Como os backups diferenciais e de log exigem um backup completo anterior para serem restauráveis, todos os três tipos de backup são eliminados 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 compressão de backup é de 3 a 4 vezes. No entanto, ela pode ser consideravelmente 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 backup 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.

A Instância Gerenciada de SQL do Azure calcula seu 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 excluído são mantidos para restauração pontual (PITR), o que pode aumentar os custos de armazenamento à medida que os backups são mantidos mesmo que o banco de dados seja excluído. Para reduzir os custos de backup, você pode alterar o período de retenção para 0 dia, mas isso só é possível para os bancos de dados excluídos. Para bancos de dados regulares, o período mínimo de retenção é de 1 dia.

Otimização do consumo de armazenamento de backup

O consumo de armazenamento de backup até o tamanho máximo de dados de um banco de dados não é cobrado. O consumo excessivo de armazenamento de backup dependerá da carga de trabalho e do tamanho máximo 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 do banco de dados ao mínimo para suas necessidades.
  • Evite fazer grandes operações de gravação, como recompilaçõ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 enfrentando altos custos excessivos com armazenamento de backup, 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

A Instância Gerenciada de SQL do Azure fornece retenção de backups de curto e longo prazo. A retenção de curto prazo permite realizar o PITR durante o período de retenção do 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, a Instância Gerenciada de SQL do Azure retêm backups suficientes para permitir o PITR nos últimos sete dias por padrão. Essa configuração pode ser alterada no intervalo de 1 a 35 dias. 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 a instância gerenciada ou para o banco de dados.

Você pode especificar a opção de redundância de armazenamento de backup para a STR ao criar sua instância e alterá-la posteriormente. Se você alterar a opção de redundância de backup depois que a instância for criada, os 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. Conforme descrito em Consumo de armazenamento de backup, os backups armazenados para habilitar a PITR podem ser mais antigos do que o período de retenção para garantir uma restauração de dados precisa.

Se você excluir um banco de dados, o sistema manterá os backups da mesma forma que faria com um banco de dados online com um período de retenção específico. No entanto, para um banco de dados excluído, o período de retenção é atualizado de 1 a 35 dias para 0 a 35 dias, possibilitando a exclusão manual dos backups. 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.

Importante

Se você precisar restaurar bancos de dados de uma instância gerenciada de SQL excluída involuntariamente, entre em contato com a equipe de suporte da Microsoft dentro de 5 dias após a operação de exclusão.

LTR (retenção de longo prazo)

Com o SQL Managed Instance, você pode configurar o armazenamento de backups LTR completos por até 10 anos no Armazenamento de Blobs do Azure. Após a política de LTR ser configurada, os backups completos são copiados automaticamente 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, configurar W=0, M=1, Y=0 criaria uma cópia LTR mensal. Para obter mais informações sobre backups de retenção de longo prazo (LTR), consulte Backups de Retenção Longo Prazo do Banco de Dados SQL do Azure e Instância Gerenciada SQL do Azure.

A redundância de armazenamento de backup LTR na Instância Gerenciada de SQL do Azure é herdada da redundância de armazenamento de backup usada pela STR no momento em que a política LTR é definida. Não é possível alterá-la, mesmo que a redundância de armazenamento de backup STR mude no futuro.

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.

Custos de armazenamento de backup

Azure SQL Managed Instance calcula o armazenamento de backup total cobrado como um valor cumulativo de 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 os backups diferenciais e de log exigem um backup completo anterior para serem restauráveis, todos os três tipos de backup são eliminados juntos em conjuntos semanais. Depois que todos os backups forem excluídos, a cobrança será interrompida.

O preço do armazenamento de backup varia. Isso depende das opções de redundância de armazenamento de backup e da região escolhida. 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 (LRS) = Zone-redundant price (ZRS) = published price
  • Geo-redundant price (GRS) = Geo-zone-redundant price (GZRS) = published price x 2

Para ver os preços, confira a página Preços da Instância Gerenciada de 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ó mostra 1,8 TB, pois você será cobrado apenas pelo armazenamento de backup em excesso usado.

Para instâncias gerenciadas, o tamanho total do armazenamento de backup faturável é agregado na instância e calculado da seguinte maneira:

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

O armazenamento de backup total faturável, se houver, é cobrado em gigabytes por mês para cada região, de acordo com a taxa de redundância de armazenamento de backup usada. O consumo de armazenamento de backup depende da carga de trabalho e do tamanho dos bancos de dados individuais e das 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 terão encargos de backup maiores.

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). A Instância Gerenciada do SQL informa ao pipeline de cobrança do Azure que o banco de dados consumiu 1 GB de backup 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. A Instância Gerenciada de SQL relatará 1 GB de uso para as horas 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 custos de retenção não aumentam imediatamente. Eles aumentam gradualmente a cada dia, porque os backups crescem até atingirem o período máximo de retenção de 14 dias.

Os cenários reais de cobrança de backup 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. 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 intensa, como a recompilaçã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:

  • 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.

Para reduzir o tamanho de todos os backups diferenciais, os backups diferenciais excessivamente grandes que excederem 750 GB e se tornarem iguais a 75% do tamanho do banco de dados serão promovidos a backups completos, se o último backup completo tiver sido feito há mais de 24 horas.

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 instância gerenciada sql para uma instância gerenciada.

  3. Adicione outro filtro para a Subcategoria do medidor.

  4. Para monitorar os custos de backup do PITR, na lista suspensa, selecione instância gerenciada pitr armazenamento de backup. Os medidores aparecem somente se houver consumo de armazenamento de backup.

    Para monitorar os custos de backup LTR, na lista suspensa, selecione instância gerenciada SQL - armazenamento de backup LTR. 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.

Captura de tela que mostra uma análise dos 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, é provável que a categoria não esteja sendo usada no momento. Por exemplo, os contadores de instância gerenciada não estarão presentes para clientes que não têm uma instância gerenciada implantada. Da mesma forma, os contadores de armazenamento não estarão visíveis para recursos que não estão consumindo armazenamento. Se não houver consumo de armazenamento de backup PITR ou LTR, esses medidores não estarão visíveis.

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 TDE, veja Criptografia de dados transparente com SQL Managed Instance.

A Microsoft é totalmente responsável por manter e fazer a rotação das chaves para bancos de dados com chaves gerenciadas pelo serviço (SMK). Os backups, PITR ou LTR, obtidos de instâncias que têm TDE com SMK habilitado podem ser restaurados pela Microsoft.

Os backups automáticos armazenados em contas de armazenamento gerenciadas pelo Azure são criptografados automaticamente pelo armazenamento do Azure. Saiba mais sobre a Criptografia de Armazenamento do Azure para dados inativos.

Problemas comuns com backups automatizados devido a ações do cliente

Embora a Instância Gerenciada de SQL do Azure forneça backups automatizados para garantir a proteção e recuperação de dados, determinadas configurações ou ações do lado do cliente podem levar a falhas de backup. Cenários comuns incluem:

  • Armazenamento insuficiente para a instância gerenciada de SQL. Se o armazenamento alocado para sua instância estiver cheio, os backups automatizados não serão feitos.
  • Os scripts ou trabalhos definidos pelo usuário que eliminam processos do sistema podem interromper operações de backup automatizadas.
  • Configurações de DNS incorretas podem impedir que a instância gerenciada de SQL acesse os pontos de extremidade necessários do Azure, incluindo aqueles usados para backups, resultando em falhas nos backups.
  • O log de transações pode ser preenchido devido à truncagem impedida pela replicação mal configurada, CDC ou armazenamento completo (no nível da instância). Se o log de transações estiver cheio e não puder ser truncado, os backups completos e diferenciais falharão, mas os backups de log ainda serão bem-sucedidos sem truncar o arquivo de log.

Para garantir backups confiáveis, é importante monitorar os recursos do sistema, validar as configurações e evitar interferir nas operações de serviço internas. Certifique-se de monitorar o armazenamento alocado, ter as configurações de DNS corretas e examinar os trabalhos personalizados e as configurações de replicação.

Integridade do backup

Todos os backups de banco de dados são obtidos com a opção CHECKSUM para fornecer integridade de backup adicional. O teste automático de backups de banco de dados automatizados pela equipe de engenharia do SQL do Azure não está disponível no momento para a Instância Gerenciada de SQL do Azure. Agende a restauração de backup de teste e o DBCC CHECKDB em seus bancos de dados na Instância Gerenciada de SQL em torno de sua carga de trabalho.

Embora o sistema não verifique a integridade dos backups, ainda há uma proteção interna de seus backups que alerta a Microsoft se houver algum problema com o serviço de backup. Além disso, a Microsoft dará suporte a você se houver algum problema com um backup, por exemplo, se um backup completo não for feito, o serviço de backup estiver paralisado, um backup de log estiver fora do escopo do SLA ou o hardware de backup ou software estiver corrompido.

Use o Azure Policy para impor 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 a instância gerenciada de 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 integradas 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ê atribuir a seguinte política interna na assinatura ou no grupo de recursos, os usuários da assinatura não poderão criar uma instância gerenciada com o armazenamento de backup com redundância geográfica por meio do portal do Azure ou do Azure PowerShell: As instâncias gerenciadas de SQL devem evitar o uso da redundância de backup GRS.

Para ver a lista completa de definições de política interna da Instância Gerenciada de SQL, confira a referência de política.

Importante

As políticas do Azure não são impostas quando você está criando um banco de dados por meio do T-SQL. Para impor 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.

Proteção de backup

Os backups da Instância Gerida de SQL do Azure são gerenciados inteiramente em assinaturas do Azure de propriedade da Microsoft, usando contas de armazenamento seguras e internas do Azure. Esses backups não são acessíveis externamente, garantindo um forte isolamento e proteção de dados. Na Microsoft, somente serviços de back-end, como o serviço Backup-Restore, têm acesso para 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.

Os backups são excluídos automaticamente após a retenção expirar.

Conformidade por meio da retenção de backup

Se a retenção padrão não atender aos seus requisitos de conformidade, você poderá alterar 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.

Observação

O artigo Alterar configurações de backup automatizado da Instância Gerenciada de SQL do Azure fornece etapas sobre como excluir dados pessoais do dispositivo ou serviço e pode ser usado para dar suporte às suas obrigações no RGPD. 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.

Conteúdo relacionado