Otimizar as estratégias de backup do SQL Server. - Recomendações da AWS
Visão geralBackup no nível do servidor usando snapshots habilitados para VSSBackup do SQL Server com o AWS BackupBackup em nível de banco de dadosRecomendações de otimização de custosRecursos adicionais

Otimizar as estratégias de backup do SQL Server.

Visão geral

A maioria das organizações busca a solução certa para proteger seus dados no SQL Server no Amazon EC2 e atender aos requisitos atuais de objetivo de ponto de recuperação (RPO), o tempo máximo aceitável desde o último backup, e de objetivo de tempo de recuperação (RTO), o atraso máximo aceitável entre a interrupção do serviço e a sua restauração. Se estiver executando o SQL Server em instâncias do EC2, há várias opções para criar backups dos seus dados e restaurá-los. As estratégias de backup para proteger os dados do SQL Server no Amazon EC2 incluem as seguintes:

Se você tiver as seguintes opções de armazenamento para database-level native backup:

Esta seção apresenta o seguinte:

  • Destaca os recursos para ajudar você a economizar espaço de armazenamento

  • Compara os custos entre as diferentes opções de armazenamento de backend

  • Fornece links para a documentação detalhada a fim de ajudar a implementar essas recomendações

Backup no nível do servidor usando snapshots habilitados para VSS

Uma arquitetura de snapshots habilitados para VSS usa o Run Command do AWS Systems Manager para instalar o agente do VSS em suas instâncias do SQL Server. Você também pode usar o Run Command para invocar todo o fluxo de trabalho de descarga dos buffers do sistema operacional e da aplicação para o disco, pausar as operações de E/S, capturar um snapshot pontual dos volumes do EBS e, em seguida, retomar a E/S.

O Run Command cria snapshots automatizados de todos os volumes do EBS anexados a uma instância de destino. Você também tem a opção de excluir o volume raiz, pois os arquivos de banco de dados do usuário geralmente são armazenados em outros volumes. Se você fizer o stripe de vários volumes do EBS para criar um único sistema de arquivos para arquivos do SQL Server, o Amazon EBS também oferecerá suporte a snapshots em vários volumes consistentes em caso de falhas usando um único comando de API. Para obter mais informações sobre snapshots do EBS habiltados para VSS consistentes com aplicações, consulte Create a VSS application-consistent snapshot na documentação do Amazon EC2.

O diagrama a seguir mostra uma arquitetura para backup no nível de servidor usando snapshots habilitados para VSS.

Arquitetura de snapshots habilitados para VSS

Considere as seguintes vantagens de usar snapshots habilitados para VSS:

  • O primeiro snapshot de uma instância de banco de dados contém os dados da instância de banco de dados completa. Os snapshots subsequentes da mesma instância de banco de dados são incrementais, o que significa que somente os dados que foram alterados depois do snapshot mais recente serão salvos.

  • Snapshots do EBS fornecem recuperação para um ponto no tempo.

  • É possível restaurar para uma nova instância do EC2 do SQL Server desde um snapshot.

  • Se uma instância for criptografada usando o Amazon EBS, ou se um banco de dados for criptografado na instância usando TDE, essa instância ou banco de dados será restaurado automaticamente com a mesma criptografia.

  • É possível copiar seus backups automatizados entre regiões.

  • Ao restaurar um volume do EBS de um snapshot, ele se torna imediatamente disponível para acesso pelas aplicações. Isso significa que você pode colocar o SQL Server online imediatamente após restaurar de snapshots um ou mais de seus volumes subjacentes do EBS.

  • Por padrão, os volumes restaurados buscam blocos subjacentes do Amazon S3 na primeira vez que uma aplicação tenta lê-los. Isso significa que pode haver um atraso na performance após a restauração de um volume do EBS a partir de um snapshot. O volume em algum momento atingirá a performance nominal. No entanto, é possível evitar esse atraso usando snapshots de restauração rápida (FSR).

  • Você pode usar o gerenciamento do ciclo de vida para snapshots do EBS.

Considere as seguintes limitações do uso de snapshots habilitados para VSS:

  • Não é possível realizar a recuperação para um ponto no tempo entre regiões com um snapshot criptografado para uma instância do SQL Server.

  • Não é possível criar um snapshot criptografado de uma instância não criptografada.

  • Não é possível restaurar um banco de dados individual porque o snapshot é obtido no nível do volume do EBS.

  • Não é possível restaurar a instância para si mesma.

  • Um snapshot da instância de banco de dados deve ser criptografado usando a mesma chave do AWS Key Management Service (AWS KMS) que a instância de banco de dados.

  • A E/S de armazenamento é suspensa por uma fração de segundo (aproximadamente 10 milissegundos) durante o processo de backup do snapshot.

Backup do SQL Server com o AWS Backup

Você pode usar o AWS Backup para centralizar e automatizar a proteção de dados nos Serviços da AWS. O AWS Backup oferece uma solução econômica, totalmente gerenciada e baseada em políticas que simplifica ainda mais a proteção de dados em grande escala. O AWS Backup também ajuda você a cumprir obrigações de conformidade regulatória e metas de continuidade de negócios. Junto com o AWS Organizations, o AWS Backup permite implantar políticas de proteção de dados (backup) de forma centralizada para configurar, gerenciar e governar sua atividade de backup em todos os recursos e Contas da AWS da sua organização.

O diagrama a seguir mostra a arquitetura de uma solução de backup e restauração para o SQL Server no EC2 usando o AWS Backup.

AWS Backup Arquitetura

Considere as seguintes vantagens de fazer backup do SQL Server usando o AWS Backup:

  • É possível automatizar os cronogramas de backup, o gerenciamento de retenção e o gerenciamento do ciclo de vida.

  • Você pode centralizar sua estratégia de backup em toda a organização e abranger várias contas e Regiões da AWS.

  • É possível centralizar o monitoramento da sua atividade de backup e os alertas nos Serviços da AWS.

  • Também é possível implementar backups entre regiões para planejar a recuperação de desastres.

  • A solução oferece suporte a backups entre várias contas.

  • É possível fazer backups seguros usando criptografia de backup secundária.

  • Todos os backups oferecem suporte a criptografia usando chaves de criptografia do AWS KMS.

  • A solução funciona com o TDE.

  • Você pode restaurar para um ponto de recuperação específico via console do AWS Backup.

  • É possível fazer backup de uma instância do SQL Server inteira, o que inclui todos os bancos de dados do SQL Server.

Backup em nível de banco de dados

Essas abordagens usam a funcionalidade nativa de backup do Microsoft SQL Server. Você pode fazer backups de bancos de dados individuais na instância do SQL Server e restaurar um banco de dados individual.

Cada uma dessas opções para backup e restauração nativas do SQL Server também oferece suporte a:

  • Compactação e backup de vários arquivos

  • Backups completos, diferenciais e T-log

  • Bancos de dados criptografados com TDE

Backup e restauração nativos do SQL Server no Amazon S3

O SQL Server no Amazon EC2 é compatível com backup e restauração nativos de bancos de dados do SQL Server. É possível fazer um backup do banco de dados do SQL Server e depois restaurar o arquivo de backup em um banco de dados existente ou em uma nova instância do EC2 do SQL Server, Amazon RDS para SQL Server ou em um servidor on-premises.

O Storage Gateway é um serviço de armazenamento em nuvem híbrida que fornece às aplicações on-premises acesso a armazenamento em nuvem praticamente ilimitado. Você pode usar o Storage Gateway para fazer backup de bancos de dados do Microsoft SQL Server diretamente no Amazon S3, reduzindo sua pegada de armazenamento on-premises e usando o Amazon S3 para armazenamento durável, escalável e econômico.

O diagrama a seguir mostra a arquitetura de uma solução nativa de backup e restauração usando o Storage Gateway e o Amazon S3.

Arquitetura do Amazon S3 e do Storage Gateway

Considere as seguintes vantagens de usar o backup nativo do SQL Server com o Storage Gateway:

  • É possível mapear um gateway de armazenamento como um compartilhamento de arquivos Server Message Block (SMB) na instância do EC2 e enviar o backup para o Amazon S3.

  • O backup ocorre diretamente no bucket do S3 ou por meio do cache de arquivos do Storage Gateway.

  • Há suporte a backups de vários arquivos.

Considere as seguintes limitações do backup nativo usando o Storage Gateway:

Para obter mais informações sobre como configurar o Storage Gateway, consulte a publicação Store SQL Server backups in Amazon S3 using AWS Storage Gateway no Blog da AWS.

Backup nativo do SQL Server em volumes do EBS

É possível fazer um backup nativo do seu banco de dados do SQL Server e armazenar o arquivo em um volume do Amazon EBS. O Amazon EBS é um serviço de armazenamento em blocos de alta performance. Os volumes do EBS são elásticos, o que é compatível com criptografia. Eles podem ser desanexados e anexados a uma instância do EC2. Você pode fazer o backup do SQL Server em uma instância do EC2 no mesmo tipo ou em um tipo diferente de volume do EBS. Uma vantagem de fazer backup em um volume diferente do EBS é a economia de custos.

O diagrama a seguir mostra a arquitetura de um backup nativo em um volume do EBS.

Arquitetura de volumes do Amazon EBS

Considere as seguintes vantagens de usar o backup nativo do SQL Server para volumes do EBS:

  • Você pode fazer backups de bancos de dados individuais em uma instância do EC2 do SQL Server e restaurar um banco de dados individual em vez de precisar restaurar a instância completa.

  • Há suporte a backups de vários arquivos.

  • É possível programar trabalhos de backup usando o SQL Server Agent e o mecanismo de trabalho do SQL Server.

  • Você pode obter benefícios de performance por meio de suas opções de hardware. Por exemplo, você pode usar volumes de armazenamento st1 para obter maior throughput.

Considere as seguintes limitações de usar backup nativo para volumes do EBS:

  • É necessário mover manualmente os backups do volume do EBS para o Amazon S3.

  • Para backups grandes, é necessário gerenciar o espaço em disco no Amazon EC2.

  • Na instância do EC2, a throughput do Amazon EBS pode ser um gargalo.

  • É necessário armazenamento adicional para armazenar backups no Amazon EBS.

Backup nativo do SQL Server no Amazon FSx para Windows File Server

O Amazon FSx para Windows File Server é um sistema de arquivos nativo do Windows totalmente gerenciado que oferece até 64 TB de armazenamento e foi desenvolvido para oferecer performance rápida, previsível e consistente. A AWS introduziu o suporte nativo a implantações de sistema de arquivos Multi-AZ no FSx para Windows File Server. O suporte nativo facilita a implantação do armazenamento de arquivos do Windows na AWS com alta disponibilidade e redundância em várias zonas de disponibilidade. A AWS também introduziu suporte para compartilhamentos de arquivos SMB de disponibilidade contínua (CA). É possível usar o FSx para Windows File Server como armazenamento de backup de um banco de dados do SQL Server.

O diagrama a seguir mostra a arquitetura de um backup nativo do SQL Server no FSx para Windows File Server.

Arquitetura de backup do FSx para Windows File Server

Considere as seguintes vantagens de usar o backup nativo do SQL Server para FSx para Windows File Server:

  • Você pode fazer backup do seu banco de dados SQL Server em um compartilhamento de arquivos do Amazon FSx.

  • Você pode fazer backups de bancos de dados individuais em uma instância do SQL Server e restaurar um banco de dados individual em vez de precisar restaurar a instância completa.

  • Os backups multipartes são compatíveis.

  • É possível programar trabalhos de backup usando o agente e o mecanismo de trabalho do SQL Server.

  • As instâncias têm maior largura de banda da rede em comparação com o Amazon EBS.

Considere as seguintes limitações de usar o backup nativo do SQL Server para FSx para Windows File Server:

  • É necessário mover manualmente os backups do Amazon FSx para o Amazon S3 usando AWS Backup ou AWS DataSync.

  • Backups grandes podem exigir uma sobrecarga adicional para o gerenciamento do espaço em disco no Amazon FSx.

  • A throughput da rede da instância do EC2 pode ser um gargalo.

  • É necessário armazenamento adicional para armazenar backups no FSx para Windows File Server.

Backup do SQL Server no Amazon FSx para NetApp ONTAP

Os snapshots com FSx para ONTAP são sempre consistentes em caso de falha, mas exigem que você desative (ou pause a E/S) seu banco de dados para criar um snapshot consistente com a aplicação. Você pode usar o NetApp SnapCenter (uma ferramenta de orquestração com plug-ins para aplicações específicas, incluindo o SQL Server) com o FSx para ONTAP a fim de criar snapshots consistentes com aplicações e proteger, replicar e clonar seus bancos de dados sem custo adicional.

NetApp SnapCenter

O NetApp SnapCenter é uma plataforma unificada para proteção de dados consistente com aplicações. O SnapCenter se refere aos snapshots como backups. Este guia adota a mesma convenção de nomenclatura. O SnapCenter fornece um painel único para gerenciar backups, restaurações e clones consistentes com aplicações. Você adiciona um plug-in do SnapCenter para sua aplicação de banco de dados específica para criar backups consistentes com as aplicações. O plug-in do SnapCenter para SQL Server fornece a funcionalidade a seguir que simplifica seu fluxo de trabalho de proteção de dados.

  • Opções de backup e restauração com granularidade para backups completos e de logs

  • Restauração no local e em um local alternativo

Para obter mais informações sobre o SnapCenter, consulte a publicação Protect your SQL Server workloads using NetApp SnapCenter with Amazon FSx for NetApp ONTAP no blog AWS Storage.

Otimização de custos para backups

As opções a seguir podem ajudar você a reduzir o custo de armazenamento de backups do SQL Server na AWS.

  • Habilite a compactação do SQL Server durante a criação do arquivo de backup e envie o menor arquivo possível para o armazenamento. Por exemplo, uma taxa de compactação de 3:1 indica que você está economizando cerca de 66% em espaço em disco. Para consultar essas colunas, você pode usar a seguinte instrução Transact-SQL: SELECT backup_size/compressed_backup_size FROM msdb..backupset;.

  • Para backups que vão para buckets do S3, habilite a classe de armazenamento Amazon S3 Intelligent-Tiering para reduzir os custos de armazenamento em 30%. 

  • Para backups que vão para o FSx para Windows File Server ou para o FSx para ONTAP, use uma única zona de disponibilidade para economizar 50% (em comparação com o uso de várias zonas de disponibilidade). Para obter informações sobre preços, consulte Preços para o Amazon FSx para Windows File Server e Amazon FSx for NetApp ONTAP Pricing.

  • A opção mais eficiente para o SQL Server 2022 é o backup direto no Amazon S3. Você pode economizar custos adicionais evitando o Storage Gateway.

Resultados do teste da avaliação comparativa de backups

Esta seção compara as opções a seguir, do ponto de vista de custo e performance, para um banco de dados de exemplo de 1 TB, com base nos resultados dos testes da avaliação comparativa de performance nas soluções de backup abordadas neste guia.

  • Especificação de instância do EC2: r5d.8xlarge com Windows Server 2019 e a edição SQL Server 2019 Developer

  • Especificação do banco de dados: 1 TB de tamanho com o TDE desabilitado

Os testes foram realizados com uma instância r5d.8xlarge e um banco de dados SQL Server de 1 TB como origem. O sistema de origem foi configurado de acordo com as práticas recomendadas, e o banco de dados de origem continha quatro arquivos de dados (250 GB cada) e um arquivo de log (50 GB) distribuídos em volumes gp3 separados. O comando BACKUP nativo do SQL Server incluiu a gravação em dez arquivos de backup usando compactação para otimizar a performance do backup e reduzir a quantidade de dados enviados pela rede e gravados no destino. Em todos os casos de teste, a performance do armazenamento foi o gargalo.

Há uma variedade quase infinita de configurações possíveis para esses tipos de teste. Esse teste se concentrou na otimização para performance, custo, escalabilidade e casos de uso reais. A tabela a seguir mostra as métricas de performance que foram capturadas para as opções de destino de backup.

Opções de backup Nível Duração da execução (Aprox.) Taxa de backup Custo em USD por mês*
Backup nativo para HDD st1 EBS local, 2 TB Banco de dados 00:30:46 min. 554.7 Mbps USD 92,16
Backup nativo para SSD gp3 EBS local, 2 TB Banco de dados 00:22:00 min. 512 Mbps USD 193,84
Backup nativo no FSx para Windows File Server HDD, throughput de 2 TB @512 Mbps Banco de dados 00:20:58 min. 814,0 Mbps USD 1.146
Backup nativo no FSx para Windows File Server SSD, throughput de 2 TB @512 Mbps Banco de dados 00:20:00 min. 814,0 Mbps USD 1.326
Backup nativo no Gateway de Arquivos do S3 m6i.4xlarge (16 vCPU, 64 GB) com 2 TB gp3 Banco de dados 00:23:20 min. 731,5 Mbps USD 470,42
Snapshot do EBS VSS Volume do EBS

00:00:02 seg.

00:00:53 seg.

 Snapshot N/A USD 51
AWS Backup (backup da AMI) AMI

00:00:04 seg.

00:08:00 min.

 Snapshot N/A $75
Backup nativo do SQL Server diretamente no Amazon S3 (SQL Server 2022) Banco de dados 00:12:00 min. 731,5 Mbps Primeiros 50 TB/mês, USD 0,023 por GB USD 23,55 por mês
Backup nativo no FSx para ONTAP (usando o SnapCenter) Banco de dados – – USD 440,20

A tabela anterior supõe o seguinte:

  • Os custos de transferência de dados e do Amazon S3 não estão incluídos.

  • O preço do armazenamento está incluído no preço da instância.

  • Os custos são baseados na região us-east-1.

  • O throughput e a IOPS aumentam em 10% com vários backups que têm uma taxa geral de alteração de 10% ao longo do mês.

Os resultados do teste mostram que a opção mais rápida é um backup nativo do banco de dados do SQL Server no FSx para Windows File Server. Um backup no Storage Gateway e nos volumes do EBS anexados localmente é a opção mais econômica, mas tem uma performance mais lenta. Para backups em nível de servidor (AMI), recomendamos usar o AWS Backup para otimizar a performance, o custo e a capacidade de gerenciamento.

Recomendações de otimização de custos

Compreender as possíveis soluções para fazer backup do SQL Server no Amazon EC2 é fundamental para proteger seus dados, garantindo que atenda às suas necessidades de backup, e colocar um plano em prática para se recuperar de eventos críticos. As diferentes formas de fazer backup e restaurar suas instâncias e bancos de dados do SQL Server analisados nesta seção podem ajudar você a criar uma estratégia de backup e restauração que proteja seus dados e atenda aos requisitos da sua organização.

Esta seção abrange as seguintes opções de backup:

  • Compactação

  • Amazon S3 Intelligent-Tiering

  • Zona de disponibilidade única

  • Backup em URL

A orientação fornecida para cada uma dessas opções é de alto nível. Se você deseja implementar alguma dessas recomendações em sua organização, recomendamos que entre em contato com a equipe da sua conta. A equipe pode então contratar um Microsoft Specialist SA para conduzir a conversa. Você também pode entrar em contato pelo e-mail optimize-microsoft@amazon.com.

Em resumo, recomendamos o seguinte:

  • Se você estiver usando o SQL Server 2022, fazer backup no Amazon S3 é a opção mais econômica.

  • Se você estiver usando o SQL Server 2019 e edições anteriores do SQL Server, considere fazer backup no Storage Gateway baseado no Amazon S3 como a opção mais econômica.

Compactação

O objetivo da compactação é ter menos armazenamento consumido por cada backup, o que é benéfico para várias opções de armazenamento. Você deve habilitar a compactação para um backup do SQL Server no nível da instância do SQL Server. O seguinte exemplo mostra como adicionar a palavra-chave de compactação com um banco de dados de backup:

BACKUP DATABASE <database_name> TO DISK WITH COMPRESSION (ALGORITHM = QAT_DEFLATE)

Amazon S3 Intelligent-Tiering

Para backups que vão para buckets do Amazon S3, você pode habilitar o Amazon S3 Intelligent-Tiering como sua classe de armazenamento do Gateway de Arquivos do Amazon S3. Isso pode reduzir os custos do armazenamento em até 30%. Em seguida, você monta o Gateway de Arquivos do S3 em seus servidores SQL usando um compartilhamento de arquivos SMB que pode ser integrado ao seu domínio do Active Directory. Isso fornece controle de acesso para seu compartilhamento, a capacidade de aproveitar contas de serviço existentes e acesso ao Amazon S3 usando um protocolo de arquivo comum focado na Microsoft. Para contas que talvez não tenham conectividade direta com um controlador de domínio, você pode usar o Active Directory Connector para facilitar a comunicação com o Active Directory on-premises ou na nuvem. Para definir as configurações do Active Directory no gateway, você deve especificar os IPs do Active Directory Connector para que o controlador de domínio faça solicitações de proxy para o Active Directory.

O diagrama a seguir mostra uma arquitetura para uma solução baseada no S3 Intelligent-Tiering.

Arquitetura de S3 Intelligent-Tiering

Por padrão, os arquivos de backup gravados no bucket do S3 usam a camada Standard. Para converter os arquivos de backup da camada Standard para o S3 Intelligent-Tiering, você deve criar uma regra de ciclo de vida. Você também pode usar o Console de gerenciamento da AWS para habilitar o S3 Intelligent-Tiering. Para obter mais informações, consulte Comece a usar o Amazon S3 Intelligent-Tiering na documentação da AWS.

Zona de disponibilidade única

Para criar um sistema de arquivos de zona de disponibilidade única, escolha a opção single-AZ ao criar um sistema de arquivos FSx para Windows File Server. O Amazon FSx também faz backups altamente duráveis (armazenados no Amazon S3) do seu sistema de arquivos diariamente usando o Windows Volume Shadow Copy Service, e permite que você faça backups adicionais a qualquer momento. Tenha em mente alguns dos problemas com o uso de uma única zona de disponibilidade. Por exemplo, o compartilhamento de arquivos SMB ficará inacessível se uma zona de disponibilidade afetada em que o sistema de arquivos é provisionado ficar inativa por várias horas. Se você precisar de acesso aos dados, deverá restaurá-los de backups em uma zona de disponibilidade disponível na região de origem. Para obter mais informações, consulte a seção Usar uma única zona de disponibilidade deste guia.

Backup em URL

Para o SQL Server 2022, o recurso de backup em URL permite o backup direto no Amazon S3. Esta é a abordagem de backup ideal para o SQL Server 2022 em execução na AWS, pois você obtém o conjunto completo de recursos do Amazon S3 na camada de armazenamento e remove o custo do dispositivo AWS Storage Gateway necessário nas versões anteriores para facilitar essa funcionalidade. Há dois custos principais a serem considerados ao implementar esse recurso: custos de transferência de dados e a classe de armazenamento S3 escolhida. Se você quiser os recursos nativos de recuperação de desastres do Amazon S3, deve considerar que a replicação entre regiões incorre em custos de saída de dados entre regiões. Para saber mais sobre como configurar essa opção, consulte a publicação Backup SQL Server databases to Amazon S3 em Microsoft Workloads no Blog da AWS.

Recursos adicionais