Serviço de backup e DR para Microsoft SQL Server

Capturar dados do SQL Server

Com o serviço de Backup e DR, é possível capturar os seguintes tipos de aplicativos do Microsoft SQL Server:

  • Instâncias

  • Bancos de dados em grupos de disponibilidade Always On

  • Grupos de consistência de bancos de dados

  • Bancos de dados individuais

  • Bancos de dados do sistema

  • Bancos de dados do usuário

  • Bancos de dados em VMs

O Backup e DR move e gerencia os dados do Microsoft SQL Server separadamente de onde o Microsoft SQL Server grava o armazenamento principal.

Um dispositivo de backup/recuperação armazena dados de aplicativos em um disco de staging. Os snapshots no disco de staging permitem que o dispositivo de backup/recuperação mantenha dados históricos.

Preparar o backup de dados do Microsoft SQL Server

A preparação para fazer backup dos dados do Microsoft SQL Server consiste em quatro etapas:

  1. Adicione servidores que hospedam bancos de dados do Microsoft SQL Server.

  2. Descubra VMs e bancos de dados do Microsoft SQL Server.

  3. Defina modelos de políticas de backup e DR e perfis de recursos de acordo com seus RPOs e RTOs.

    Os bancos de dados que usam o modelo de recuperação completa do Microsoft SQL Server podem capturar o banco de dados e os registros dele. Portanto, um banco de dados capturado pode ser recuperado até um ponto no tempo ao rolar os registros para frente.

  4. Atribua modelos de políticas e perfis de recursos do Backup and DR a bancos de dados do Microsoft SQL Server.

Captura de dados

Ao capturar dados, considere o seguinte:

  • Um disco de staging é criado e montado automaticamente em um servidor.

  • Uma cópia completa inicial é feita no disco de staging. As cópias subsequentes consistem apenas de blocos alterados.

  • O disco de teste é desmontado do servidor.

  • Um snapshot do disco de staging é feito no dispositivo de backup/recuperação.

Capturar registros de banco de dados do SQL Server

A captura de registros do banco de dados é definida em Detalhes e configurações de uma política de snapshot. Ela permite que uma única política de snapshot capture registros de bancos de dados do Microsoft SQL Server e grupos de consistência que contêm bancos de dados do Microsoft SQL Server.

A frequência com que os registros do banco de dados são capturados é definida separadamente da frequência do banco de dados. Por exemplo, um banco de dados pode ser capturado todos os dias, e os registros dele, a cada hora.

A frequência do backup do registro do banco de dados é definida em minutos, e a frequência de captura dos registros não pode exceder a frequência de captura do banco de dados associado. Por exemplo, se a frequência de captura de um banco de dados for a cada 24 horas, a frequência de captura do arquivo de registro precisará ser igual ou menor que a cada 24 horas.

A retenção de registros também é definida separadamente do banco de dados associado. Ter períodos de retenção separados permite manter informações de registro suficientes para cobrir todas as versões de snapshot e OnVault de um banco de dados. Por exemplo, se os dados de snapshot de um banco de dados forem mantidos por três dias e os dados do OnVault por sete dias, você poderá definir a retenção de registros para abranger todos os sete dias. Neste exemplo, uma única imagem de banco de dados capturada pode ser selecionada e os registros dela podem ser transferidos para frente durante todo o período.

Os registros do banco de dados são armazenados em um único disco de staging no pool de snapshots do Backup e DR. Para economizar espaço no pool de snapshots, use uma configuração avançada para instruir o banco de dados a compactar os registros.

É possível especificar a replicação de registros de transações do banco de dados do Microsoft SQL Server para um dispositivo remoto de backup/recuperação. É possível usar os registros no site remoto para qualquer imagem de banco de dados dentro do intervalo de retenção dos registros replicados.

Redimensionar o disco de staging do registro do banco de dados

O espaço físico necessário para acomodar backups dos registros de um banco de dados é gerenciado automaticamente pelo Backup e DR. Isso é chamado de disco de preparação de registros e é separado do armazenamento gerenciado pelo servidor de origem. No mínimo, o Backup and DR avalia os tamanhos típicos de registros e o período de armazenamento deles e usa um disco maior, se necessário.

Para gerenciar de forma mais eficiente e eficaz os requisitos de armazenamento dos registros de um banco de dados, as políticas de snapshot oferecem as seguintes configurações avançadas:

  • Período de retenção de backup de registros: a retenção de registros é definida separadamente do banco de dados associado. Com taxas de retenção separadas, você mantém informações de registro suficientes para abranger todas as versões de snapshot de um banco de dados. O período de armazenamento de registros é uma configuração obrigatória.

  • Crescimento do tamanho do disco de preparação de registros: define a porcentagem em que o disco de preparação em que os registros residem vai crescer automaticamente.

  • Taxa de mudança estimada: define a mudança diária (porcentagem), o que permite que o dispositivo de backup/recuperação calcule melhor o tamanho do disco de staging necessário para armazenar registros.

  • Compactar backup de registros do banco de dados: instrui o banco de dados de origem a compactar os registros antes da captura no dispositivo de backup/recuperação. O servidor de banco de dados realiza a compactação de registros durante o backup de registros (o padrão é Ativado).

Opções de captura de dados do SQL Server

As seções a seguir abordam as opções de captura de dados do SQL Server.

Capturar instâncias, bancos de dados individuais e grupos de bancos de dados

O agente de Backup e DR é usado para capturar instâncias, bancos de dados de usuários, bancos de dados de sistema e grupos de bancos de dados em servidores físicos e virtuais.

Ao capturar uma instância do SQL Server, você tem a opção de capturar a instância inteira ou bancos de dados selecionados dentro dela. Quando você protege a instância inteira, os bancos de dados adicionados a ela são incluídos automaticamente no próximo job de captura do Backup e DR. Os bancos de dados em uma instância são colocados em estado inativo e capturados com um único plano de backup.

Se o Backup e DR e a captura de banco de dados e registros estiverem ativados na política do plano de backup, todos os bancos de dados nessa instância poderão ser recuperados para o mesmo momento. A recuperação e o avanço dos registros de todos os bancos de dados ou de bancos de dados individuais em uma instância são realizados na interface do usuário do Backup e DR com uma única ação.

Os membros individuais de uma instância podem ser acessados por operações de montagem, clonagem, LiveClone e restauração, conforme necessário.

Capturar grupos de consistência

Um grupo de consistência é um grupo de bancos de dados que são colocados em estado inativo e capturados juntos com um único modelo de política de plano de backup e perfil de recurso. A associação a um grupo de consistência é atribuída manualmente e é adequada para grupos de bancos de dados cujos membros não mudam com muita frequência. Para proteger automaticamente novos membros de um grupo de bancos de dados, crie e proteja esses bancos em uma instância do SQL Server.

Como o nome sugere, os grupos de consistência garantem a captura e a recuperação pontual consistentes em vários bancos de dados. Se a tecnologia de captura de banco de dados e registros do Backup and DR estiver ativada na política do plano de backup, todos os bancos de dados desse grupo poderão ser recuperados para o mesmo ponto no tempo. A recuperação e o avanço dos registros de todos os bancos de dados ou de um banco de dados específico em um grupo de consistência são realizados na interface do usuário do Backup e DR com uma única ação. Os membros de um grupo de consistência precisam estar na mesma instância.

Um grupo de consistência pode ser composto pelo seguinte:

  • Um ou mais bancos de dados do sistema

  • Um ou mais bancos de dados de usuários

  • Bancos de dados do sistema ou do usuário juntos

  • Zero ou mais sistemas de arquivos (letras de unidade ou pontos de montagem)

Os membros individuais de um grupo de consistência podem ser acessados por operações de montagem, clonagem, LiveClone e restauração.

Os bancos de dados em uma instância de failover em cluster precisam ser descobertos no nó ativo. Depois de protegido, o GO segue o nó SQL ativo em um cluster. Os jobs de proteção continuam sendo executados mesmo em uma condição de failover. Além de tornar as operações de captura e acesso rápidas, os grupos de consistência consomem menos recursos do sistema (VDisks) do que a proteção individual de bancos de dados.

Para validar a integridade do backup do banco de dados periodicamente, monte uma imagem de backup em um servidor e execute uma verificação de consistência do banco de dados. É possível usar o recurso de fluxo de trabalho para automatizar o processo de validação.

Capturar os bancos de dados e o volume de inicialização de uma VM

Ao capturar bancos de dados em VMs, você também pode capturar o volume de inicialização da VM. Quando o volume de inicialização de uma VM é capturado com os bancos de dados, uma imagem pode ser apresentada como um banco de dados e uma VM totalmente funcionais. A imagem pode ser migrada para um novo local permanente.

Replicar dados do SQL Server

Os dados podem ser replicados para um segundo dispositivo de backup/recuperação ou para a nuvem com fins de recuperação, recuperação de desastres, teste ou desenvolvimento. A replicação de dados sempre foi um obstáculo para o gerenciamento eficiente de dados em um ambiente distribuído geograficamente. A replicação de backup e DR resolve esses problemas com a compactação, que:

  • Reduz o uso geral da rede.

  • Elimina a necessidade de um acelerador ou otimizador de WAN dedicado.

  • Criptografa dados usando o padrão de criptografia AES-256. A autenticação entre dispositivos de backup/recuperação é realizada usando certificados de 1024 bits.

A replicação é controlada pelas políticas de modelo de política de backup e DR:

  • As políticas de produção para espelhamento têm várias opções para replicar dados em um segundo dispositivo de backup/recuperação.

  • As políticas de produção para OnVault usam um mecanismo proprietário do Backup e DR para transferir dados para o armazenamento de objetos.

Replicar registros

Quando a opção Ativar backup de registro do banco de dados de uma política é definida como Ativar, a configuração avançada Replicar registros permite que os registros de transações do banco de dados do Microsoft SQL Server sejam replicados para um dispositivo remoto de backup/recuperação. Para que um job de replicação de registros seja executado, é necessário incluir no modelo uma política de replicação do StreamSnap e um perfil de recurso que especifique um dispositivo de backup/recuperação remoto. Além disso, é preciso concluir pelo menos uma replicação do banco de dados. Em seguida, use os registros no site remoto para qualquer imagem de banco de dados dentro do intervalo de retenção dos registros replicados. Essa função é ativada por padrão.

A replicação de registros usa a tecnologia StreamSnap para realizar a replicação entre os dispositivos de backup/recuperação locais e remotos. A replicação de registros vai diretamente do pool de snapshots local para o pool de snapshots no dispositivo remoto.

Os registros também podem ser replicados para um pool do OnVault. Quando ativados (não padrão), os registros são enviados a cada pool do OnVault especificado por uma política ou combinação de perfil de recurso válida do OnVault (por exemplo, O pool do OnVault selecionado na política e o pool do OnVault especificado no perfil de recurso. A retenção de registros no pool do OnVault sempre corresponde à retenção de registros no pool de snapshots.

Acessar dados do SQL Server

Para bancos de dados do Microsoft SQL Server que usam o modelo de recuperação completa, o Backup e DR pode apresentar instantaneamente uma cópia do banco de dados transferida para um ponto específico. A operação de substituição é especificada no console de gerenciamento.

Para bancos de dados do Microsoft SQL Server que usam o modelo de recuperação básica, o Backup e DR pode apresentar instantaneamente qualquer backup do banco de dados que não tenha passado do período de armazenamento.

Independente do modelo de recuperação do Microsoft SQL Server usado, os dados do Microsoft SQL Server podem ser acessados usando a interface iSCSI. Se você estiver usando o VMware (GCVE), os dados também poderão ser acessados usando um armazenamento de dados NFS apresentado ao host ESXi.

Controle de acesso baseado em papéis

Você pode controlar quais usuários têm acesso a dados, recursos e recursos do Backup and DR. Os dados capturados podem ser marcados como sensíveis, e os usuários do Backup e DR podem receber permissão de acesso a eles.

Suportes

A função de montagem do Backup e DR oferece acesso instantâneo aos dados sem precisar movê-los. As cópias capturadas de bancos de dados podem ser avançadas usando a interface do usuário do Backup and DR e montadas em qualquer servidor de banco de dados. O Backup e DR oferece duas maneiras de montar um banco de dados do Microsoft SQL Server:

  • A montagem do aplicativo virtual apresenta e disponibiliza os dados capturados do Microsoft SQL Server para um servidor de destino como um banco de dados do Microsoft SQL Server. Isso permite criar e gerenciar cópias de bancos de dados de produção para uso que não seja de produção. As montagens de aplicativos virtuais são criadas no dispositivo de backup/recuperação e não exigem intervenção manual dos administradores de banco de dados, servidor ou armazenamento. Montagens de aplicativos virtuais podem ser usadas para relatórios de banco de dados, análises, testes de integridade e testes e desenvolvimento. Os bancos de dados virtuais são detalhados em Montar um banco de dados do SQL Server como um novo banco de dados virtual e Montar bancos de dados em grupos de disponibilidade Always On do SQL.

  • A montagem padrão, também chamada de montagem direta, apresenta e disponibiliza os dados capturados do Microsoft SQL Server para um servidor de destino como um sistema de arquivos, não como um banco de dados. Isso é útil se um banco de dados estiver corrompido ou perdido ou se um servidor de banco de dados estiver sendo substituído. Nesses casos, não é possível usar uma operação de restauração para recuperar o banco de dados. Em vez disso, você pode ativar uma imagem e copiar os arquivos do banco de dados da imagem ativada para o local original no servidor de banco de dados. As montagens diretas são detalhadas em Montar dados capturados do Microsoft SQL.

LiveClones

Um LiveClone é uma cópia independente de dados do Microsoft SQL Server que pode ser atualizada e mascarada antes de ser disponibilizada aos usuários. Isso permite que as equipes de desenvolvimento e teste trabalhem com o conjunto de dados mais recente sem precisar gerenciar os dados manualmente ou interferir no ambiente de produção.

Clones

A função de clonagem move uma cópia dos dados de produção para um local diferente da origem. O tempo necessário para concluir uma operação de clonagem depende da quantidade de dados envolvidos. Os clones são detalhados em Clonar bancos de dados do SQL Server.

Restaurações

Uma restauração reverte os dados de produção para um momento especificado. As operações de restauração movem dados. As operações de restauração geralmente são realizadas após uma corrupção de dados em massa. O tempo necessário para concluir uma operação de restauração depende da quantidade de dados envolvidos.

Para restaurar um banco de dados e aplicar registros, o banco de dados restaurado precisa estar no modo de restauração. É possível restaurar o banco de dados no modo de restauração e, em seguida, avançar os registros para um momento específico. Se você restaurar o banco de dados sem especificar Restaurar sem recuperação, o banco de dados será restaurado e ficará on-line sem aplicar registros. As restaurações são detalhadas em Restaurar bancos de dados do SQL Server. Para uma restauração com tempo de inatividade quase zero, primeiro ative os dados, conforme detalhado em Ativar e migrar dados SQL.

Workflows para automatizar o acesso a dados do SQL Server

Workflows automatizam o acesso aos dados capturados do Microsoft SQL Server. Workflows podem apresentar dados como uma montagem direta ou como um LiveClone:

  • As montagens diretas (padrão ou com reconhecimento de aplicativos) funcionam bem para dados do Microsoft SQL Server que não precisam ser mascarados antes da apresentação. Uma cópia montada de dados pode ser atualizada manualmente ou automaticamente em uma programação. Com as montagens diretas, você pode acessar instantaneamente os dados capturados do Microsoft SQL Server sem precisar movê-los.

  • Um LiveClone é uma cópia dos dados de produção do Microsoft SQL Server que pode ser atualizada manualmente ou de acordo com uma programação. É possível mascarar dados sensíveis em um LiveClone antes de disponibilizá-lo aos usuários.

Ao combinar a captura de dados automatizada do Microsoft SQL Server e o controle de acesso do Backup e DR com fluxos de trabalho e recursos opcionais de mascaramento de dados, é possível criar ambientes de autoprovisionamento. Os usuários podem provisionar os próprios ambientes quase instantaneamente.

Por exemplo, um administrador do Backup e DR pode criar uma política de modelo de backup que captura dados do Microsoft SQL Server de acordo com uma programação especificada. O administrador pode marcar os dados capturados do Microsoft SQL Server de produção como sensíveis e acessíveis apenas por usuários com os direitos de acesso adequados.

Depois que os direitos de acesso são definidos e os dados são capturados, o administrador pode criar um fluxo de trabalho que:

  • Disponibiliza os dados capturados do Microsoft SQL Server como um LiveClone ou uma montagem direta.

  • Atualiza os dados do LiveClone ou do Microsoft SQL Server montável de forma programada ou sob demanda.

  • Opcionalmente, aplica scripts automaticamente aos dados do Microsoft SQL Server do LiveClone após cada atualização. Isso é útil para mascarar dados sensíveis do Microsoft SQL Server.

Quando o fluxo de trabalho for concluído, os usuários com acesso adequado poderão provisionar os ambientes com os dados do LiveClone ou do Microsoft SQL Server montável.

Backup e DR trabalhando com produtos de backup atuais

À medida que mais empresas buscam acelerar o desenvolvimento de aplicativos usando bancos de dados de produção, o Backup e DR geralmente é necessário para coexistir com produtos de backup legados que trabalham nos mesmos ambientes de banco de dados de produção. O backup e a DR podem coexistir perfeitamente com outros produtos que capturam dados de bancos de dados de produção, desde que essas práticas recomendadas sejam seguidas.

O Backup e DR tem um método proprietário de rastreamento de blocos de mudanças. Assim, as soluções de backup que usam SQL ou outros métodos de obtenção de backups não são afetadas por jobs de captura de dados programados do Backup e DR.

Os jobs de backup podem exigir muita E/S. Eles podem ter longa duração e afetar a performance do banco de dados durante as janelas de backup. O Backup e DR minimiza o impacto durante os jobs, mas até mesmo uma atualização incremental permanente no nível do bloco precisa gerar alguma E/S e leva um pouco de tempo.

Requisito Não programe o software de backup legado e o Backup e DR para executar jobs de forma que haja sobreposição de tempo.
Prática recomendada Programe os jobs de banco de dados do Backup e DR para começar em um horário em que o software de backup legado já tenha terminado. Não programe a execução do software de backup legado imediatamente após a conclusão normal de um job do Backup e DR.
Motivo Se os jobs de backup legados e os jobs do Backup e DR forem executados simultaneamente, isso poderá resultar em um impacto grave no desempenho do servidor de banco de dados, causando instabilidade e possivelmente uma interrupção.

Os registros de banco de dados são usados para capturar transações individuais em um banco de dados, permitindo recuperações pontuais. A maioria dos casos de uso de agilidade se concentra em receber snapshots de banco de dados periodicamente da produção. A frequência comum varia de diária a semanal ou uma vez a cada duas semanas, dependendo do caso de uso. Como resultado, os desenvolvedores de aplicativos geralmente não precisam posicionar a instância de não produção em um ponto específico no tempo da origem (produção). Isso geralmente elimina a necessidade de capturar e gerenciar registros como parte de uma solução de agilidade de backup e DR.

Requisito Apenas um sistema pode gerenciar (capturar ou truncar (limpar)) registros, seja o software de backup legado ou o Backup e DR.
Prática recomendada Continue permitindo que todo o gerenciamento de registros seja feito pelo software de backup legado. Não use o Backup e DR para proteger registros nesse ambiente.
Motivo Se o sistema estiver configurado para gerenciar (capturar ou truncar/remover) registros e o software de backup legado também estiver capturando e/ou truncando/removendo registros, um ou ambos os sistemas poderão acabar com uma cadeia de registros incompleta, dificultando ou impossibilitando a recuperação do banco de dados para um ponto específico no tempo.

Outra documentação do Backup e DR para Microsoft SQL Server

Esta página faz parte de uma série de páginas específicas para proteger e recuperar bancos de dados do Microsoft SQL Server com o Backup e DR. Para mais informações, consulte:

A seguir

Prepare bancos de dados do SQL Server para o serviço de backup e DR.