Backups automatizados na Instância Gerenciada SQL do Azure

  • Artigo

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

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

Para alterar as configurações de backup, consulte Alterar configurações. Para restaurar um backup, consulte Recuperar usando backups automatizados de banco de dados.

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 de negócios e recuperação de desastres, pois ajudam a proteger seus dados contra corrupção ou exclusão. A Instância Gerenciada SQL do Azure fornece backups do mecanismo de banco de dados do SQL Server completamente gerenciados e automatizados. Esses backups permitem a restauração do banco de dados para um point-in-time específico dentro do período de retenção configurado, até 35 dias. No entanto, se as regras de proteção de dados exigirem que os backups estejam disponíveis por um período prolongado (até 10 anos), você poderá configurar políticas de retenção de longo prazo (LTR) por banco de dados.

Frequência de cópia de segurança

A Instância Gerenciada SQL do Azure cria:

  • Backups completos todas as semanas.
  • Backups diferenciais a cada 12 horas.
  • Backups de log de transações a cada ~10 minutos.

A frequência dos backups de log de transações depende do tamanho da 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, em sua respetiva ordem.

Redundância de armazenamento de cópias de segurança

Por padrão, a Instância Gerenciada SQL do Azure armazena dados em blobs de armazenamento com redundância geográfica que são replicados para uma região emparelhada. A redundância geográfica ajuda a proteger contra interrupções que afetam o armazenamento de backup na região principal. Ele também permite que você restaure sua instância para uma região diferente no caso de um desastre.

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

Para garantir que os backups permaneçam na mesma região onde o banco de dados está implantado, você pode alterar a redundância do armazenamento de backup do armazenamento com redundância geográfica padrão para outros tipos de armazenamento que mantêm os dados dentro da região. Para saber mais sobre redundância de armazenamento, consulte Redundância de dados.

Você pode configurar a redundância de armazenamento de backup ao criar sua instância e atualizá-la posteriormente no nível da instância. As alterações feitas em uma instância existente aplicam-se apenas a backups futuros. Depois de atualizar a redundância de armazenamento de backup de uma instância existente, pode levar até 24 horas para que as alterações sejam aplicadas. As alterações feitas na redundância de armazenamento de backup aplicam-se apenas a backups de curto prazo. As políticas de retenção de longo prazo herdam a opção de redundância de backups de curto prazo quando a política é criada. 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.

Nota

Observe que a alteração de redundância de backup causa uma etapa de atualização que inicia um failover.

Você pode escolher uma das seguintes redundâncias de armazenamento para backups:

  • LRS (armazenamento com redundância local): copia os backups de forma síncrona três vezes em um único local físico na região principal. O LRS é a opção de replicação mais barata, mas não o recomendamos para aplicativos que exigem alta disponibilidade ou durabilidade.

    Diagram showing the locally redundant storage (LRS) option.

  • Armazenamento com redundância de zona (ZRS): copia seus backups de forma síncrona em três zonas de disponibilidade do Azure na região primária. Atualmente está disponível em determinadas regiões.

    Diagram showing the zone-redundant storage (ZRS) option.

  • Armazenamento com redundância geográfica (GRS): copia seus backups de forma síncrona três vezes em um único local físico na região principal 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 principal dentro de uma única zona de disponibilidade.
    • Três cópias síncronas na região emparelhada 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.

    Diagram showing the geo-redundant storage (GRS) option.

  • Armazenamento com redundância de zona geográfica (GZRS): combina a alta disponibilidade proporcionada pela redundância em zonas de disponibilidade com a proteção contra interrupções regionais proporcionada pela replicação geográfica. Os dados em uma conta 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 copiadas da região primária para a região secundária de forma assíncrona.

    Diagram showing the geo-zone-redundant storage (GZRS) option.

Aviso

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

Utilização de cópias de segurança

Pode utilizar estas cópias de segurança para:

  • Restaure um banco de dados existente para um ponto no tempo 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. Esta operação cria um novo banco de dados na mesma instância do banco de dados original ou em uma instância diferente na mesma assinatura e região. Ele usa um nome diferente para evitar a substituição do banco de dados original. Você também pode usar o portal do Azure para restaurar seu backup de banco de dados point-in-time para uma instância em uma assinatura diferente da sua instância de origem.

    Após a conclusão da restauração, pode eliminar a base de dados original. Como alternativa, você pode renomear o banco de dados original e renomear o banco de dados restaurado para o nome do banco de dados original.

  • Restaure um banco de dados excluído para um ponto no tempo dentro do período de retenção, incluindo o tempo de exclusão. Você pode restaurar o banco de dados excluído para a mesma instância gerenciada em que o backup foi feito, ou outra instância na mesma ou uma assinatura diferente para a instância de origem. Antes de excluir um banco de dados, o serviço faz um backup final do log de transações para evitar qualquer perda de dados.

  • Restaure uma base de dados para outra região geográfica. O restauro geográfico permite-lhe recuperar de desastres geográficos quando não consegue aceder à base de dados ou às cópias de segurança na região principal. Ele cria um novo banco de dados em qualquer instância gerenciada existente em qualquer região do Azure.

    Importante

    A restauração geográfica está disponível apenas para bancos de dados configurados com armazenamento de backup com redundância geográfica. Se não estiver a utilizar atualmente cópias de segurança georreplicadas para uma base de dados, pode alterar isto ao configurar a redundância do armazenamento de cópias de segurança.

  • Restaure um banco de dados a partir de um backup de longo prazo de um banco de dados, se o banco de dados tiver uma política LTR configurada. O LTR permite restaurar uma versão mais antiga do banco de dados usando o portal do Azure, a CLI do Azure ou o Azure PowerShell para satisfazer uma solicitação de conformidade ou executar uma versão antiga do aplicativo. Para obter mais informações, consulte a página Visão geral da retenção de longo prazo.

Recursos e funcionalidades de restauro

Esta tabela resume os recursos e as capacidades de restauração point-in-time (PITR), restauração geográfica e retenção de longo prazo.

Propriedades das cópias de segurança  PITR Restauro geográfico LTR
Tipos de cópias de segurança de SQL Backups completos, diferenciais e de log de transações. Cópias replicadas de cópias de segurança PITR. Apenas backups completos.
Objetivo de ponto de recuperação (RPO)  Aproximadamente 10 minutos, com base no tamanho da computação e na quantidade de atividade do banco de dados.   Até 1 hora, com base na replicação geográfica. 1    Uma semana (ou política do utilizador).
Objetivo de tempo de recuperação (RTO) A restauração geralmente leva menos de 12 horas, mas pode levar mais tempo, dependendo do tamanho e da atividade. Veja Recuperação.  A restauração geralmente leva menos de 12 horas, mas pode levar mais tempo, dependendo do tamanho e da atividade. Veja Recuperação. A restauração geralmente leva menos de 12 horas, mas pode levar mais tempo, dependendo do tamanho e da atividade. Veja Recuperação.
Retenção 1 a 35 dias.  Ativada por predefinição, o mesmo que a origem. 2 Não ativado por padrão. A retenção é de até 10 anos.
Armazenamento do Azure   Redundância geográfica por predefinição. Opcionalmente, você pode configurar o armazenamento com redundância de zona ou localmente redundante. Disponível quando a redundância de armazenamento de cópias de segurança PITR estiver definida como georredundante. Não disponível quando o armazenamento de backup PITR é redundante em zona ou localmente redundante.  Redundância geográfica por predefinição. Você pode configurar o armazenamento com redundância de zona ou localmente redundante.
Configurar backups como imutáveis Não suportado Não suportado Não suportado
Restaurando um novo banco de dados na mesma região Suportado Suportado  Suportado
Restaurando um novo banco de dados em outra região Não suportado Suportado em qualquer região do Azure Suportado em qualquer região do Azure
Restaurando um novo banco de dados em outra assinatura Suportado Não suportado 3 Não suportado 3
Restaurando por meio do portal do Azure Sim Sim Sim
Restaurando via PowerShell Sim Sim Sim
Restaurando 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 PITR são armazenados em armazenamento com redundância geográfica por padrão, o que significa que a restauração geográfica está habilitada por padrão.

3 A solução alternativa é restaurar para um novo servidor e usar Resource Move para mover o servidor para outra assinatura.

Restaurar um banco de dados a partir do backup

Para executar uma restauração, consulte Restaurar um banco de dados a partir de backups. Você pode tentar a configuração de backup e operações de restauração usando os exemplos a seguir.

Operação Portal do Azure CLI do Azure Azure PowerShell
Alterar a retenção de backup Instância gerenciada SQL do Banco de dados / SQL Instância gerenciada SQL do Banco de dados / SQL Instância gerenciada SQL do Banco de dados / SQL
Alterar a retenção de backup de longo prazo Instância gerenciada SQL do Banco de dados / SQL Instância gerenciada SQL do Banco de dados / SQL Instância gerenciada SQL do Banco de dados / SQL
Restaurar um banco de dados a partir de um point-in-time Instância gerenciada SQL do Banco de dados / SQL Instância gerenciada SQL do Banco de dados / SQL Instância gerenciada SQL do Banco de dados / SQL
Restaurar uma base de dados eliminada Instância gerenciada SQL do Banco de dados / SQL Instância gerenciada SQL do Banco de dados / SQL Instância gerenciada SQL do Banco de dados / SQL
Restaurar um banco de dados do Armazenamento de Blobs do Azure Instância gerenciada SQL

Agendamento automático de backups

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

Cópia de segurança inicial

  • Novos bancos de dados: imediatamente após um banco de dados ser criado, restaurado ou sofrer alterações de redundância de backup, o primeiro backup completo é iniciado. Esse backup normalmente é concluído em 30 minutos, embora possa levar mais tempo para bancos de dados maiores.

  • Bancos de dados restaurados: a duração do backup inicial para bancos de dados restaurados varia e depende do tamanho do banco de dados. Bancos de dados restaurados ou cópias de banco de dados, que geralmente são maiores, podem exigir mais tempo para o backup inicial.

Backups completos agendados

  • Programação semanal: o sistema define uma janela semanal de backup completo para toda a instância.
  • Janela de backup completo: Este é um período designado quando backups completos são executados. Embora o sistema tenha como objetivo concluir backups completos dentro dessa janela, se necessário, o backup pode continuar além do tempo agendado até ser concluído.
  • Programação adaptável: o algoritmo de backup avalia o impacto da janela de backup na carga de trabalho aproximadamente uma vez por semana, usando o uso da CPU e a taxa de transferência de E/S como indicadores. Dependendo da carga de trabalho da semana anterior, a janela de backup completo pode ser ajustada.
  • Configuração do usuário: é crucial observar que os usuários não podem modificar ou desativar o agendamento de backup.

Importante

Para um banco de dados novo, restaurado ou copiado, o recurso de restauração point-in-time (PITR) fica disponível quando o backup inicial do log de transações que segue o backup completo inicial é criado.

Consumo de armazenamento de backup

Com a tecnologia de backup e restauração do SQL Server, a restauração de um banco de dados para um point-in-time requer 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.

As agendas de backup da Instância Gerenciada SQL do Azure incluem um backup completo por semana. Para fornecer PITR durante todo o período de retenção, o sistema deve armazenar backups adicionais completos, diferenciais e de log de transações por até uma semana a mais do que o período de retenção configurado.

Em outras palavras, para qualquer point-in-time durante o período de retenção, deve haver um backup completo mais antigo do 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 desde esse 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 backups diferenciais e backups de log exigem um backup completo anterior para serem restauráveis, 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 por TDE, todos os backups completos e diferenciais são compactados, para reduzir a compactação e os custos do armazenamento de backup. A taxa média de compactação de backup é de 3 a 4 vezes. No entanto, pode ser significativamente 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.

A Instância Gerenciada SQL do Azure calcula o armazenamento de backup total usado como um valor acumulado. A cada hora, esse valor é relatado para o pipeline de cobrança do Azure. O pipeline é responsável por agregar esse uso horário 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 envelhecem e são excluídos. Depois que todos os backups são excluídos e o PITR não é mais possível, o faturamento é interrompido.

Importante

Os backups de um banco de dados excluído são mantidos para restauração point-in-time (PITR), o que pode aumentar os custos de armazenamento, pois os backups são mantidos mesmo que o banco de dados seja excluído. Para reduzir custos, você pode definir o período de retenção de backup para 0 dias, mas apenas para bancos de dados excluídos. Para bases de dados regulares, o período mínimo de retenção é de 1 dia.

Ajustar o consumo do armazenamento de cópias de segurança

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 depende da carga de trabalho e do tamanho máximo dos bancos de dados individuais. Considere algumas das seguintes técnicas de ajuste 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 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 siga as práticas recomendadas relacionadas. Considere também reduzir o número de índices não agrupados.
  • 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ê tiver custos de armazenamento de backup em excesso 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 armazenamento de backup localmente redundante sempre que possível (por exemplo, ambientes de desenvolvimento/teste).

Retenção da cópia de segurança

A Instância Gerenciada SQL do Azure fornece retenção de backups de curto e longo prazo. 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, a Instância Gerenciada SQL do Azure retém backups suficientes para permitir o PITR nos últimos 7 dias por padrão. Esta configuração pode ser alterada no intervalo de 1 a 35 dias. O serviço realiza backups completos regulares, diferenciais e de log para garantir que os bancos de dados sejam restauráveis para qualquer point-in-time dentro do período de retenção definido para o banco de dados ou a instância gerenciada.

Você pode especificar sua opção de redundância de armazenamento de backup para STR ao criar sua instância e, em seguida, alterá-la posteriormente. Se você alterar a opção de redundância de backup após a criação da instância, 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 STR anterior não são movidas ou copiadas. Eles são deixados na conta de armazenamento original até que o período de retenção expire. 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 para garantir uma restauração precisa dos dados.

Se você excluir um banco de dados, o sistema manterá backups da mesma forma que faria para um banco de dados on-line com seu 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-35 dias para 0-35 dias, tornando possível excluir backups manualmente. Se você precisar manter backups por mais tempo do que o período máximo de retenção de curto prazo de 35 dias, poderá habilitar a retenção de longo prazo.

Importante

Se eliminar uma instância gerida, todas as bases de dados nessa instância gerida também serão eliminadas e não poderão ser recuperadas. Não pode restaurar uma instância gerida eliminada. Mas se você configurou a retenção de longo prazo para uma instância gerenciada, os backups LTR não serão excluídos. Em seguida, você pode usar esses backups para restaurar bancos de dados para uma instância gerenciada diferente na mesma assinatura, até um ponto no tempo em que um backup LTR foi feito. Para saber mais, consulte Restaurar backup de longo prazo.

Retenção de longo prazo (LTR)

Com a Instância Gerenciada do SQL, você pode configurar o armazenamento de backups LTR completos por até 10 anos no Armazenamento de Blobs do Azure. Depois que a política LTR é configurada, os backups completos são copiados automaticamente para um contêiner de armazenamento diferente.

Para atender a vários requisitos de conformidade, você pode 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, Y=0 criaria uma cópia LTR mensal. Para obter mais informações sobre LTR, consulte Retenção de longo prazo.

A redundância de armazenamento de backup LTR na Instância Gerenciada 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á-lo, mesmo que a redundância do armazenamento de backup STR mude no futuro.

O consumo do armazenamento depende da frequência e dos períodos de retenção das cópias de segurança LTR selecionados. Pode utilizar a calculadora de preços LTR para estimar o custo do armazenamento LTR.

Custos de armazenamento da cópia de segurança

A Instância Gerenciada SQL do Azure calcula seu armazenamento de backup total faturável 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 à medida que os backups mais antigos envelhecerem e forem excluídos. Como backups diferenciais e backups de log exigem um backup completo anterior para serem restauráveis, todos os três tipos de backup são limpos juntos em conjuntos semanais. Depois que todos os backups são excluídos, o faturamento é interrompido.

O preço do armazenamento de backup varia. Depende da opção de redundância de armazenamento de backup escolhida e da sua região. O armazenamento de backup é cobrado com base nos gigabytes consumidos por mês, com a mesma taxa para todos os backups.

A redundância do 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
  • Geo-zone-redundant price = published price x 3.4

Para obter preços, consulte a página de preços da Instância Gerenciada SQL do Azure.

Nota

Uma fatura do Azure mostra apenas o consumo excessivo de armazenamento de backup, não todo o consumo de armazenamento de backup. Por exemplo, em um cenário hipotético, se você tiver provisionado 4 TB de armazenamento de dados, obterá 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 mostrará apenas 1,8 TB, porque você será cobrado apenas pelo excesso de armazenamento de backup usado.

Para instâncias gerenciadas, o tamanho total do armazenamento de backup faturável é agregado no nível da 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 total de backup 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 de bancos de dados individuais e instâncias gerenciadas. Bancos de dados fortemente modificados têm backups diferenciais e de log maiores, porque o tamanho desses backups é proporcional à quantidade de dados alterados. Portanto, esses bancos de dados terão taxas de backup mais altas.

Como um exemplo simplificado, suponha que um banco de dados acumulou 744 GB de armazenamento de backup e que essa quantidade permanece constante durante um mês inteiro porque o banco de dados está completamente ocioso. Para converter esse consumo acumulado de armazenamento em uso por hora, divida-o por 744,0 (31 dias por mês vezes 24 horas por dia). A Instância Gerenciada do SQL relata 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 faturação do Azure agrega este consumo e mostra uma utilização de 744 GB durante todo o mês. O custo é baseado na taxa de gigabytes por mês na sua região.

Aqui está 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 faz com que o armazenamento total de backup duplique para 1.488 GB. A Instância Gerenciada SQL relataria 1 GB de uso por horas de 1 a 372 (a primeira quinzena do mês). Ele relataria o uso como 2 GB por horas 373 a 744 (a segunda metade do mês). Esse uso seria agregado a uma conta 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 faturamento 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 também varia. O consumo por hora do armazenamento de backup flutua de acordo.

Cada backup diferencial também contém todas as alterações feitas no banco de dados desde o último backup completo. Assim, o tamanho total de todos os backups diferenciais aumenta gradualmente ao longo de uma semana. Em seguida, ele cai drasticamente 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 a reconstruçã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 serão então incluídas:

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

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

Monitorizar os custos

Para entender os custos de armazenamento de backup, vá para Gerenciamento de custos + Cobrança no portal do Azure. Selecione Gerenciamento de custos e, em seguida, selecione Análise de custos. Selecione a subscrição pretendida para o Âmbito e, em seguida, filtre o período de tempo e o serviço em que está interessado da seguinte forma:

  1. Adicione um filtro para 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 Medidor.

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

    Para monitorar os custos de backup LTR, na lista suspensa, selecione sql managed instance - ltr backup storage. Os medidores aparecem somente se houver consumo de armazenamento de backup.

As subcategorias Armazenamento e computação também podem interessá-lo, mas não estão associadas aos custos de armazenamento de backup.

Screenshot that shows an analysis of backup storage costs.

Importante

Os medidores são visíveis apenas para contadores que estão atualmente em uso. 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 serã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 serão visíveis.

Cópias de segurança encriptadas

Se a sua base de dados estiver encriptada com TDE, as cópias de segurança são encriptadas automaticamente de forma inativa, incluindo as cópias de segurança LTR. Todas as novas bases de dados no SQL do Azure são configuradas com o TDE ativado por predefinição. Para obter mais informações sobre TDE, consulte Criptografia de dados transparente com instância gerenciada SQL.

Integridade do backup

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

Embora o sistema não verifique a integridade dos backups, ainda há proteção interna dos backups que alerta a Microsoft se houver um problema com o serviço de backup. Além disso, a Microsoft oferece suporte se ocorrer um problema com um backup, como se um backup completo não for feito, o serviço de backup estiver preso, um backup de log estiver fora do SLA ou se o hardware ou software de backup estiver corrompido.

Usar a Política do Azure para impor redundância de armazenamento de backup

Se você tiver requisitos de residência de dados que exijam que você mantenha todos os seus dados em uma única região do Azure, convém impor backups redundantes de zona ou localmente redundantes para sua instância gerenciada do SQL usando a Política do Azure.

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-o a manter estes recursos em conformidade com os seus padrões empresariais e contratos de nível de serviço. Para obter mais informações, consulte Visão geral da Política do Azure.

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

Para impor requisitos de residência de dados em um nível organizacional, você pode atribuir políticas a uma assinatura usando o portal do Azure ou o Azure PowerShell. Por exemplo, se você atribuir a seguinte política interna no nível de assinatura ou grupo de recursos, os usuários na assinatura não poderão criar uma instância gerenciada com armazenamento de backup com redundância geográfica por meio do portal do Azure ou do Azure PowerShell: As Instâncias Gerenciadas SQL devem evitar o uso da redundância de backup GRS.

Para obter uma lista completa das definições de política internas para a Instância Gerenciada SQL, revise a referência de política.

Importante

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

Conformidade

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

Nota

O artigo Alterar configurações de backup automatizado fornece etapas sobre como excluir dados pessoais do dispositivo ou serviço e pode ser usado para dar suporte às suas obrigações sob o GDPR. Para obter informações gerais sobre o RGPD, consulte a secção RGPD do Centro de Confiança da Microsoft e a secção RGPD do Portal de Confiança do Serviço.

Próximos passos