Backups automatizados na Base de Dados SQL do Azure

Aplica-se a: Base de Dados SQL do Azure

Este artigo descreve a funcionalidade de cópia de segurança automatizada para SQL do Azure Database.

Para alterar as definições de backup, consulte as definições de Alterar. Para restaurar uma cópia de segurança, consulte Recuperar utilizando cópias de segurança de base de dados automatizadas.

O que é uma cópia de segurança da base de dados?

As cópias de dados são uma parte essencial de qualquer estratégia de continuidade de negócios e recuperação de desastres, porque ajudam a proteger os seus dados da corrupção ou eliminação. Estas cópias de segurança permitem que a base de dados restabeleça um ponto no tempo dentro do período de retenção configurado. Se as suas regras de proteção de dados exigirem que as suas cópias de segurança estejam disponíveis por um período prolongado (até 10 anos), pode configurar a retenção a longo prazo (LTR) para bases de dados individuais e aginhadas.

Para níveis de serviço que não o Hyperscale, SQL do Azure Database utiliza SQL Server tecnologia do motor para fazer o back up e restaurar os dados. As bases de dados de hiperescala utilizam cópias de segurança e restauram com base em imagens de armazenamento. Com a tecnologia de backup tradicional SQL Server, as bases de dados maiores têm longos tempos de backup/restauro. Com o uso de instantâneos, a Hyperscale fornece capacidades instantâneas de backup e restauro rápido, independentemente do tamanho da base de dados. Para saber mais, consulte os backups da Hyperscale.

Frequência de cópia de segurança

SQL do Azure Database cria:

A frequência exata das cópias de segurança dos registos de transações baseia-se no tamanho do cálculo e na quantidade de atividade da base de dados. Quando restaura uma base de dados, o serviço determina quais as cópias de segurança completas, diferenciais e de registo de transações que precisam de ser restauradas.

A arquitetura Hyperscale não requer cópias de segurança completas, diferenciais ou de registo. Para saber mais, consulte os backups da Hyperscale.

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

Por padrão, SQL do Azure Database armazena cópias de segurança em bolhas de armazenamento geo-redundantes que são replicadas numa região emparelhada. A geo-redundância ajuda a proteger contra falhas que afetam o armazenamento de backup na região primária. Também lhe permite restaurar as suas bases de dados numa região diferente em caso de paralisação regional.

O mecanismo de despedimento de armazenamento armazena várias cópias dos seus dados para que seja protegido de eventos planeados e não planeados. Estes eventos podem incluir falhas de hardware transitórias, falhas de rede ou de energia, ou desastres naturais maciços.

Para garantir que as suas cópias de segurança permanecem na mesma região onde a sua base de dados é implantada, pode alterar a redundância de armazenamento de backup do armazenamento geo-redundante padrão para outros tipos de armazenamento que mantêm os seus dados dentro da região. A redundância de armazenamento de backup configurada é aplicada tanto a cópias de segurança de retenção de curto prazo (STR) como a cópias de segurança LTR. Para saber mais sobre a redundância de armazenamento, consulte a redundância de dados.

Pode configurar a redundância de armazenamento de cópias de segurança quando criar a sua base de dados, e pode atualizá-la mais tarde. As alterações que faz a uma base de dados existente aplicam-se apenas a futuras cópias de segurança. Depois de atualizar a redundância de armazenamento de backup de uma base de dados existente, as alterações podem demorar até 48 horas a serem aplicadas.

Pode escolher um dos seguintes despedimentos de armazenamento para backups:

  • Armazenamento localmente redundante (LRS): Copia os seus backups sincronizadamente três vezes num único local físico na região primária. O LRS é a opção de armazenamento menos dispendiosa, mas não recomendamos para aplicações que exijam resiliência a interrupções regionais ou uma garantia de alta durabilidade de dados.

    Diagrama que mostra a opção de armazenamento localmente redundante (LRS).

  • Armazenamento redundante de zona (ZRS): Copia as suas cópias de segurança sincronizadamente em três zonas de disponibilidade de Azure na região primária. Atualmente está disponível em apenas certas regiões.

    Diagrama que mostra a opção de armazenamento redundante de zona (ZRS).

  • Armazenamento geo-redundante (GRS): Copia as suas cópias de segurança sincronizadamente três vezes num único local físico na região primária utilizando LRS. Em seguida, copia os seus dados assíncronamente três vezes para um único local físico na região secundária emparelhada .

    O resultado é:

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

    Diagrama que mostra a opção de armazenamento geo-redundante (GRS).

Aviso

  • A geo-restauração é desativada assim que uma base de dados é atualizada para utilizar armazenamento localmente redundante ou redundante de zona.
  • Os diagramas de redundância de armazenamento mostram regiões com múltiplas zonas de disponibilidade (multi-az). No entanto, existem algumas regiões que fornecem apenas uma única zona de disponibilidade e não apoiam o ZRS.
  • A redundância de armazenamento de backup para bases de dados hyperscale só pode ser definida durante a criação. Não é possível modificar esta definição depois de o recurso ser aprovisionado. Para atualizar as definições de redundância de armazenamento de cópias de segurança para uma base de dados de Hiperescala existente com tempo mínimo de inatividade, utilize a geo-replicação ativa. Em alternativa, pode utilizar a cópia da base de dados. Saiba mais em backups de Hiperescala e redundância de armazenamento.

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

Pode utilizar backups criados automaticamente nos seguintes cenários:

  • Restaurar uma base de dados existente a um ponto no tempo dentro do período de retenção, utilizando o portal do Azure, Azure PowerShell, o CLI Azure ou a API REST. Esta operação cria uma nova base de dados no mesmo servidor que a base de dados original, mas utiliza um nome diferente para evitar a sobreescrita da base de dados original.

    Após a restauração dos acabamentos, pode eliminar opcionalmente a base de dados original e mudar o nome da base de dados restaurada para o nome original da base de dados. Em alternativa, em vez de eliminar a base de dados original, pode renomeá-la e, em seguida, mudar o nome da base de dados restaurada para o nome original da base de dados.

  • Restaurar uma base de dados eliminada a um ponto no tempo dentro do período de retenção, incluindo o tempo de eliminação. A base de dados eliminada só pode ser restaurada no mesmo servidor onde criou a base de dados original. Antes de eliminar uma base de dados, o serviço recebe uma cópia de segurança final do registo de transações para evitar qualquer perda de dados.

  • Restaure uma base de dados para outra região geográfica. O geo-restauro permite-lhe recuperar de uma paragem regional quando não consegue aceder à sua base de dados ou cópias de segurança na região primária. Cria uma nova base de dados em qualquer servidor existente em qualquer região do Azure.

    Importante

    O geo-restauro está disponível apenas para bases de dados configuradas com armazenamento de backup geo-redundante. 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.

  • Restaurar uma base de dados a partir de uma cópia de segurança específica a longo prazo de uma base de dados única ou agrária, se a base de dados tiver sido configurada com uma política LTR. O LTR permite restaurar uma versão mais antiga da base de dados utilizando o portal do Azure, o CLI Azure, ou Azure PowerShell para satisfazer um pedido de conformidade ou executar uma versão mais antiga da aplicação. Para obter mais informações, veja Retenção de longa duração.

Restaurar capacidades e funcionalidades

Esta tabela resume as capacidades e características da restauração pontual (PITR), geo-restauração e retenção a longo prazo.

Propriedade de backup  Restauro para um Ponto Anterior no Tempo Georrestauro LTR
Tipos de cópias de segurança de SQL Completo, diferencial, log. Cópias replicadas de cópias de segurança PITR. Apenas as cópias de segurança completas.
Objetivo de ponto de recuperação (RPO)  10 minutos, com base no tamanho do cálculo e na quantidade de atividade da base de dados.   Até 1 hora com base na georreplicação.*  Uma semana (ou política do utilizador).
Objetivo de tempo de recuperação (RTO) A restauração geralmente demora menos de 12 horas, mas pode demorar mais tempo, dependendo do tamanho e da atividade. Veja Recuperação A restauração geralmente demora menos de 12 horas, mas pode demorar mais tempo, dependendo do tamanho e da atividade. Veja Recuperação. A restauração geralmente demora menos de 12 horas, mas pode demorar mais tempo, dependendo do tamanho e da atividade. Veja Recuperação.
Retenção 7 dias por defeito, configurável até 35 dias.  Ativada por predefinição, o mesmo que a origem.** Não ativado por defeito. A retenção é de até 10 anos.
Armazenamento do Azure   Redundância geográfica, por predefinição. Pode configurar opcionalmente o armazenamento redundante ou redundante localmente. 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 ou localmente redundante.  Redundância geográfica por predefinição. Pode configurar armazenamento redundante ou localmente redundante.
Restaurar uma nova base de dados na mesma região Suportado Suportado  Suportado
Restaurar uma nova base de dados noutra região Não suportado Suportado em qualquer região do Azure Suportado em qualquer região do Azure
Restaurar uma nova base de dados em outra subscrição Não suportado Não suportado*** Não suportado***
Restaurar via portal do Azure Yes Yes Yes
Restaurar via PowerShell Yes Yes Yes
Restauro via Azure CLI Yes Yes Yes

* Para aplicações críticas ao negócio que exijam grandes bases de dados e que garantam a continuidade do negócio, utilize grupos de falha automática.

** Todas as cópias de segurança PITR são armazenadas em armazenamento geo-redundante por defeito, pelo que a geo-restauração é ativada por predefinição.

A solução é restaurar para um novo servidor e usar o Movimento de Recursos para mover o servidor para outra subscrição, ou usar uma cópia de base de dados de subscrição cruzada.

Restaurar uma base de dados a partir de backup

Para efetuar uma restauração, consulte Restaurar uma base de dados a partir de backups. Pode explorar a configuração de backup e restaurar as operações utilizando os seguintes exemplos.

Operação Portal do Azure CLI do Azure Azure PowerShell
Alterar a retenção de backup Base de Dados SQL
Instância Gerida do SQL
Base de Dados SQL
Instância Gerida do SQL
Base de Dados SQL
Instância Gerida do SQL
Alterar a retenção de backup a longo prazo Base de Dados SQL
Instância Gerida do SQL
Base de Dados SQL
Instância Gerida do SQL
Base de Dados SQL
Instância Gerida do SQL
Restaurar uma base de dados a partir de um ponto no tempo Base de Dados SQL
Instância Gerida do SQL
Base de Dados SQL
Instância Gerida do SQL
Base de Dados SQL
Instância Gerida do SQL
Restaurar uma base de dados eliminada Base de Dados SQL
Instância Gerida do SQL
Base de Dados SQL
Instância Gerida do SQL
Base de Dados SQL
Instância Gerida do SQL

Agendamento de backup

A primeira cópia de segurança completa é agendada imediatamente após a criação ou o restauro de uma nova base de dados. Esta cópia de segurança geralmente termina em 30 minutos, mas pode demorar mais tempo quando a base de dados é grande. Por exemplo, a cópia de segurança inicial pode demorar mais tempo numa base de dados restaurada ou numa cópia de base de dados, que normalmente seria maior do que uma nova base de dados.

Após o primeiro backup completo, todos os backups adicionais são agendados e geridos automaticamente. O prazo exato de todas as cópias de segurança de base de dados é determinado pelo serviço de Base de Dados SQL, pois este equilibra a carga de trabalho global do sistema. Não pode alterar o horário dos trabalhos de reserva ou desativá-los.

Importante

  • Para uma nova base de dados, restaurada ou copiada, a capacidade de restauro pontual fica disponível quando a cópia de segurança inicial do registo de transações que segue a cópia de segurança inicial é criada.
  • As bases de dados de hiperescala são protegidas imediatamente após a criação, ao contrário de outras bases de dados onde a cópia de segurança inicial leva tempo. A proteção é imediata mesmo que a base de dados Hyperscale tenha sido criada com uma grande quantidade de dados através de cópia ou restauro. Para saber mais, reveja as cópias de segurança automatizadas hyperscale.

Consumo de armazenamento de backup

Com SQL Server a tecnologia de backup e restauro, restaurar uma base de dados a um ponto no tempo requer uma cadeia de backup ininterrupta. Essa cadeia consiste numa cópia de segurança completa, opcionalmente uma cópia de segurança diferencial e uma ou mais cópias de segurança de registo de transações.

SQL do Azure Base de Dados agenda uma cópia de segurança completa todas as semanas. Para fornecer PITR durante todo o período de retenção, o sistema deve armazenar cópias de segurança adicionais completas, diferenciais e de registo de transações por um período máximo de uma semana superior ao período de retenção configurado.

Por outras palavras, para qualquer ponto do tempo durante o período de retenção, deve haver um backup completo que seja mais antigo do que o tempo mais antigo do período de retenção. Deve também existir uma cadeia ininterrupta de cópias de segurança diferenciais e de registo de transações a partir dessa cópia de segurança completa até à próxima cópia de segurança completa.

Bases de dados de hiperescala usam um mecanismo de agendamento de backup diferente. Para mais informações, consulte o agendamento de backup da Hyperscale.

As cópias de segurança que já não são necessárias para fornecer a funcionalidade PITR são automaticamente eliminadas. Como as cópias de segurança diferenciais e as cópias de segurança requerem uma cópia de segurança completa anterior para serem restauradoras, os três tipos de backup são purgados em conjuntos semanais.

Para todas as bases de dados, incluindo bases de dados encriptadas por TDE , as cópias de segurança são comprimidas para reduzir o consumo e os custos de armazenamento de backup. A relação média de compressão de backup é de 3 a 4 vezes. No entanto, pode ser significativamente menor ou maior dependendo da natureza dos dados e se a compressão de dados é usada na base de dados.

SQL do Azure Database calcula o armazenamento total de backup usado como um valor cumulativo. A cada hora, este valor é reportado ao oleoduto de faturação do Azure. O oleoduto é responsável pela agregação deste uso horário para calcular o seu consumo no final de cada mês. Após a base de dados ser eliminada, o consumo diminui à medida que as cópias de segurança envelhecem e são eliminadas. Depois de todas as cópias de segurança serem eliminadas e o PITR já não ser possível, a faturação para.

Importante

As cópias de segurança de uma base de dados são mantidas para fornecer PITR mesmo que a base de dados tenha sido eliminada. Embora a eliminação e recriação de uma base de dados possa poupar custos de armazenamento e computação, pode aumentar os custos de armazenamento de backup. A razão é que o serviço retém cópias de segurança para cada base de dados eliminada, sempre que é eliminada.

Monitorizar o consumo

Para bases de dados vCore em SQL do Azure Base de Dados, o armazenamento que cada tipo de cópia de segurança (completa, diferencial e log) consome é reportado no painel de monitorização da base de dados como uma métrica separada. A imagem que se segue mostra como monitorizar o consumo de armazenamento de cópia de segurança para uma única base de dados.

Screenshot que mostra seleções para monitorizar o consumo de backup da base de dados no portal do Azure.

Para obter instruções sobre como monitorizar o consumo em Hiperescala, consulte o consumo de backup do Monitor Hyperscale.

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

O consumo do armazenamento de cópias de segurança até ao tamanho máximo dos dados para uma base de dados não é cobrado. O consumo excessivo do armazenamento de cópias de segurança dependerá da carga de trabalho e do tamanho máximo das bases de dados individuais. Considere algumas das seguintes técnicas de afinação para reduzir o seu consumo de armazenamento de backup:

  • Reduza o período de retenção de backup ao mínimo para as suas necessidades.
  • Evite fazer grandes operações de escrita, como reconstruções de índices, mais frequentemente do que o necessário.
  • Para grandes operações de carga de dados, considere a utilização de índices de loja de colunas agrupados e as melhores práticas relacionadas. Considere também reduzir o número de índices não agrupados.
  • No nível de serviço Fins Gerais, o armazenamento de dados forvisionado é mais barato do que o preço do armazenamento de backup. Se tiver custos de armazenamento de backup em excesso continuamente elevados, poderá considerar aumentar o armazenamento de dados para economizar no armazenamento de backup.
  • Utilize o TempDB em vez de tabelas permanentes na lógica de aplicação para armazenar resultados temporários ou dados transitórios.
  • Utilize armazenamento de backup localmente redundante sempre que possível (por exemplo, ambientes dev/teste).

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

SQL do Azure Database fornece a retenção a curto e a longo prazo de cópias de segurança. A retenção a curto prazo permite que o PITR dentro do período de retenção para a base de dados. A retenção a longo prazo fornece cópias de segurança para vários requisitos de conformidade.

Retenção de curto prazo

Para todas as bases de dados novas, restauradas e copiadas, SQL do Azure Database retém cópias de segurança suficientes para permitir o PITR nos últimos 7 dias por padrão. O serviço requer regularmente cópias de segurança completas, diferenciais e de registo para garantir que as bases de dados são ressaltadas a qualquer ponto dentro do período de retenção definido para a base de dados.

A retenção de 1 a 35 dias para bases de dados de hiperescala está agora em pré-visualização. Para saber mais, reveja a gestão da retenção de backup em Hyperscale.

As cópias de segurança diferenciais podem ser configuradas para ocorrer uma vez em 12 horas ou uma em 24 horas. Uma frequência de backup diferencial de 24 horas pode aumentar o tempo necessário para restaurar a base de dados, em comparação com a frequência de 12 horas. No modelo vCore, a frequência predefinitiva para cópias de segurança diferenciais é uma vez em 12 horas. No modelo DTU, a frequência predefinida é uma vez em 24 horas.

Pode especificar a sua opção de redundância de armazenamento de cópia de segurança para a STR quando criar a sua base de dados e, em seguida, alterá-la posteriormente. Se alterar a sua opção de redundância de backup após a criação da base de dados, as novas cópias de segurança utilizarão a nova opção de despedimento. As cópias de cópias de segurança feitas com a opção de redundância str anterior não são movidas ou copiadas. Ficam na conta de armazenamento original até que o período de retenção expire, o que pode ser de 1 a 35 dias.

Com exceção das bases de dados básicas, pode alterar o período de retenção de backup para cada base de dados ativa no intervalo de 1 a 35 dias. Conforme descrito no consumo de armazenamento de backup, as cópias de segurança armazenadas para permitir o PITR podem ser mais antigas do que o período de retenção. Se precisar de manter as cópias de segurança durante mais tempo do que o período máximo de retenção de curto prazo de 35 dias, pode permitir a retenção a longo prazo.

Se eliminar uma base de dados, o sistema mantém as cópias de segurança da mesma forma que faria para uma base de dados online com o seu período de retenção específico. Não é possível alterar o período de retenção de cópias de segurança para uma base de dados eliminada.

Importante

Se eliminar um servidor, todas as bases de dados desse servidor também são eliminadas e não podem ser recuperadas. Não é possível restaurar um servidor apagado. Mas se configurar a retenção a longo prazo para uma base de dados, as cópias de segurança LTR não são eliminadas. Em seguida, pode utilizar essas cópias de segurança para restaurar bases de dados num servidor diferente na mesma subscrição, a um ponto do tempo em que foi recolhida uma cópia de segurança LTR. Para saber mais, reveja Restaurar o backup a longo prazo.

Retenção de longa duração

Para Base de Dados SQL, pode configurar cópias de segurança LTR completas até 10 anos em Armazenamento de Blobs do Azure. Após a configuração da política LTR, as cópias de segurança completas são automaticamente copiadas para um recipiente de armazenamento diferente semanalmente.

Para satisfazer vários requisitos de conformidade, pode selecionar diferentes períodos de retenção para backups completos semanais, mensais e/ou anualmente. A frequência depende da apólice. Por exemplo, a definição W=0, M=1 criaria uma cópia LTR mensalmente. Para mais informações sobre o LTR, consulte a retenção a longo prazo.

A atualização do despedimento de armazenamento de cópia de segurança para uma base de dados existente aplica a alteração apenas às cópias de segurança subsequentes tomadas no futuro e não às cópias de segurança existentes. Todas as cópias de segurança LTR existentes para a base de dados continuarão a residir na bolha de armazenamento existente. Novas cópias de segurança serão replicadas com base na redundância de armazenamento de backup configurada.

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 de backup

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

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

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

Para obter preços, consulte a página de preços da base de SQL do Azure.

Nota

Uma fatura Azure mostra apenas o consumo excessivo de armazenamento de backup, não todo o consumo de armazenamento de backup. Por exemplo, num cenário hipotético, se tiver disponibilizado 4 TB de armazenamento de dados, obterá 4 TB de espaço de armazenamento de backup gratuito. Se utilizar um total de 5.8 TB de espaço de armazenamento de backup, a fatura Azure mostrará apenas 1.8 TB, porque é cobrado apenas para armazenamento de cópia de segurança em excesso que usou.

Modelo de DTU

No modelo DTU, não há custo adicional para armazenamento de backup para bases de dados e piscinas elásticas. O preço do armazenamento de backup é uma parte da base de dados ou preço da piscina.

Modelo de vCore

SQL do Azure Database calcula o seu armazenamento total de backup facturalável como um valor cumulativo em todos os ficheiros de backup. A cada hora, este valor é reportado ao oleoduto de faturação do Azure. O oleoduto agrega este uso de hora a hora para obter o seu consumo de armazenamento de reserva no final de cada mês.

Se uma base de dados for eliminada, o consumo de armazenamento de cópias de segurança diminuirá gradualmente à medida que as cópias de segurança mais antigas envelhecem e são eliminadas. Como as cópias de segurança diferenciais e as cópias de segurança requerem uma cópia de segurança completa anterior para serem restauradoras, os três tipos de backup são purgados em conjuntos semanais. Depois de todas as cópias de segurança serem eliminadas, a faturação para.

O custo de armazenamento de backup é calculado de forma diferente para bases de dados de Hiperescala. Para obter mais informações, consulte os custos de armazenamento de backup da Hyperscale.

Para bases de dados individuais, é fornecido um valor de armazenamento de backup igual a 100% do tamanho máximo de armazenamento de dados para a base de dados, sem custos adicionais. A seguinte equação é utilizada para calcular o total do armazenamento de backup faturada:

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

Para piscinas elásticas, uma quantidade de armazenamento de reserva igual a 100 por cento do armazenamento máximo de dados para o tamanho de armazenamento da piscina é fornecida sem custos adicionais. Para bases de dados agráveis, o tamanho total do armazenamento de backup faturado é agregado ao nível da piscina e é calculado da seguinte forma:

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

O armazenamento total de backup facturalável, se houver, é cobrado em gigabytes por mês de acordo com a taxa da redundância de armazenamento de backup que usou. Este consumo de armazenamento de backup depende da carga de trabalho e do tamanho de bases de dados individuais, piscinas elásticas e instâncias geridas. As bases de dados fortemente modificadas têm maior diferencial e cópias de segurança de registo, porque o tamanho destas cópias de segurança é proporcional à quantidade de dados alterados. Por conseguinte, estas bases de dados terão encargos de backup mais elevados.

Como exemplo simplificado, assuma que uma base de dados acumulou 744 GB de armazenamento de backup e que este valor permanece constante durante todo um mês porque a base de dados está completamente inativa. Para converter este consumo acumulado de armazenamento para uso horário, divida-o em 744,0 (31 dias por mês vezes 24 horas por dia). Base de Dados SQL informará ao oleoduto de faturação da Azure que a base de dados consumia 1 GB de backup PITR a cada hora, a uma taxa constante. A faturação do Azure irá agregar este consumo e mostrar um uso de 744 GB durante todo o mês. O custo será baseado na taxa para gigabytes por mês na sua região.

Aqui está outro exemplo. Suponha que a mesma base de dados ociosa tenha a sua retenção aumentada de 7 dias para 14 dias em meados do mês. Este aumento resulta na duplicação total do armazenamento de backup para 1.488 GB. Base de Dados SQL reportaria 1 GB de uso durante as horas 1 a 372 (a primeira metade do mês). Reportaria o uso como 2 GB durante as horas 373 a 744 (a segunda metade do mês). Este uso seria agregado a uma nota final de 1.116 GB por mês.

Os cenários reais de faturação de backup são mais complexos. Como a taxa de alterações na base de dados depende da carga de trabalho e é variável ao longo do tempo, o tamanho de cada diferencial e cópia de segurança de registo também variará. O consumo horária de armazenamento de backup irá oscilar em conformidade.

Cada cópia de segurança diferencial também contém todas as alterações es feitas na base de dados desde a última cópia de segurança completa. Assim, o tamanho total de todos os backups diferenciais aumenta gradualmente ao longo de uma semana. Em seguida, cai acentuadamente depois de um conjunto mais antigo de completa, diferencial, e os backups de log envelhecem.

Por exemplo, assuma que uma atividade de escrita pesada, como uma reconstrução de índice, é executado logo após a conclusão de uma cópia de segurança completa. As modificações que o índice de reconstrução faz serão então incluídas:

  • Nos registos de transações, as cópias de segurança assumidas durante a vigência da reconstrução.
  • No próximo diferencial.
  • Em cada cópia de segurança diferencial tomada até que o próximo backup completo ocorra.

Para o último cenário em bases de dados maiores, uma otimização no serviço cria uma cópia de segurança completa em vez de uma cópia de segurança diferencial se uma cópia de segurança diferencial for excessivamente grande de outra forma. Isto reduz o tamanho de todos os backups diferenciais até ao seguinte backup completo.

Pode monitorizar o consumo total de armazenamento de backup para cada tipo de cópia de segurança (registo completo, diferencial, de transação) ao longo do tempo, conforme descrito no consumo do Monitor.

Monitorizar os custos

Para compreender os custos de armazenamento de backup, vá à Cost Management + Billing no portal do Azure. Selecione Gestão de Custos e, em seguida, selecione análise de custos. Selecione a subscrição desejada para Scope e, em seguida, filtre pelo período de tempo e serviço que lhe interessa da seguinte forma:

  1. Adicione um filtro para o nome de serviço.

  2. Na lista de dropdown, selecione a base de dados sql para uma única base de dados ou uma piscina de base de dados elástica.

  3. Adicione outro filtro para a subcategoria meter.

  4. Para monitorizar os custos de backup pitr, na lista de dropdown, selecione o armazenamento de backup de backup de piscina único/elástico pitr para uma única base de dados ou uma piscina de base de dados elástica. Os contadores só aparecerão se o consumo de armazenamento de reserva existir.

    Para monitorizar os custos de backup LTR, na lista de dropdown, selecione o armazenamento de cópias de segurança ltr para uma única base de dados ou um pool de base de dados elástico. Os contadores só aparecerão se o consumo de armazenamento de reserva existir.

As subcategorias de Armazenamento e Computação também podem interessar-lhe, mas não estão associados a custos de armazenamento de backup.

Screenshot que mostra uma análise dos custos de armazenamento de backup.

Importante

Os contadores são visíveis apenas para balcões que estão atualmente a ser utilizados. Se um contador não estiver disponível, é provável que a categoria não esteja atualmente a ser utilizada. Por exemplo, os balcões de armazenamento não serão visíveis para recursos que não consomem armazenamento. Se não houver um consumo de armazenamento de backup PITR ou LTR, estes contadores não serão visíveis.

Para mais informações, consulte SQL do Azure Gestão de custos da Base de Dados.

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 o TDE, consulte a encriptação de dados transparente com Base de Dados SQL.

Integridade de backup

De um modo contínuo, equipa de engenharia do SQL do Azure testa automaticamente o restauro das cópias de segurança de bases de dados automatizadas. Após a restauração pontual, as bases de dados também recebem verificações de integridade do DBCC CHECKDB.

Quaisquer problemas encontrados durante uma verificação de integridade resultarão num alerta para a equipa de engenharia. Para mais informações, consulte a integridade dos dados em Base de Dados SQL.

Todas as cópias de segurança da base de dados são tomadas com a opção CHECKSUM para fornecer integridade adicional de backup.

Conformidade

Quando migra a base de dados de um escalão de serviço baseado em DTU para um escalão de serviço baseado em vCore, a retenção PITR é preservada para garantir que a política de recuperação de dados da sua aplicação não é posta em risco. Se a retenção por defeito não cumprir os seus requisitos de conformidade, pode alterar o período de retenção pitr. Para obter mais informações, consulte Alterar o período de retenção de backup pitr.

Nota

O artigo de definições de cópias de segurança automatizadas Change fornece passos sobre como eliminar dados pessoais do dispositivo ou serviço e pode ser usado para suportar as suas obrigações no âmbito do RGPD. Para obter informações gerais sobre o RGPD, consulte a secção RGPD do Microsoft Trust Center e a secção RGPD do portal Service Trust.

Use Azure Policy para impor redundância de armazenamento de backup

Se tiver requisitos de residência de dados que exijam que mantenha todos os seus dados numa única região de Azure, talvez queira impor backups redundantes ou locais para a sua base de dados SQL utilizando Azure Policy.

Azure Policy é um serviço que pode usar para criar, atribuir e gerir políticas que aplicam regras aos recursos da Azure. Azure Policy ajuda-o a manter estes recursos em conformidade com os seus padrões corporativos e acordos de nível de serviço. Para mais informações, consulte a visão geral da Azure Policy.

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

Para impor os requisitos de residência de dados a nível organizacional, pode atribuir políticas a uma subscrição utilizando o portal do Azure ou Azure PowerShell. Por exemplo, se atribuir a seguinte política incorporada, os utilizadores na subscrição não poderão criar uma base de dados com armazenamento de backup geo-redundante através do portal do Azure ou Azure PowerShell: Base de Dados SQL deve evitar usar redundância de backup GRS.

Para obter uma lista completa das definições políticas incorporadas para Base de Dados SQL, reveja a referência política.

Importante

As políticas de Azure não são aplicadas quando se está a criar uma base de dados via T-SQL. Para especificar a residência de dados quando estiver a criar uma base de dados utilizando O T-SQL, utilize o LOCAL ou a ZONA como entrada para o parâmetro BACKUP_STORAGE_REDUNDANCY na declaração CREATE DATABASE.

Passos seguintes