Serviço de backup e DR para Microsoft SQL Server

Capturar dados do SQL Server

O serviço de backup e DR permite capturar os seguintes tipos de aplicativos do Microsoft SQL Server:

  • Instâncias

  • Bancos de dados em grupos de disponibilidade sempre ativados

  • 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 a DR movem e gerenciam 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 preparação. Os snapshots no disco de preparação 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 para um determinado ponto no tempo avançando os registros.

  4. Atribua modelos de política de backup e DR e perfis de recursos a bancos de dados do Microsoft SQL Server.

Captura de dados

Ao capturar dados, considere o seguinte:

  • Um disco de preparação é criado e montado automaticamente em um servidor.

  • Uma cópia inicial completa é feita no disco de preparação. As cópias subsequentes consistem apenas em blocos alterados.

  • O disco de preparação é desconectado do servidor.

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

Capturar registros de banco de dados do SQL Server

A captura de registros de banco de dados é definida nos Detalhes e configurações de uma política de snapshots. Ele ativa uma política de snapshot única para capturar 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 logs dele a cada hora.

A frequência do backup de registro do banco de dados é definida em minutos, e a frequência em que os registros são capturados não pode exceder a frequência em que o banco de dados associado é capturado. Por exemplo, se a frequência de captura de um banco de dados for a cada 24 horas, a frequência de captura de arquivos de registro precisa ser igual ou menor que 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 todos os snapshots e versões do 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 forem mantidos 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 avançados durante todo o período.

Os registros do banco de dados são armazenados em um único disco de preparação no conjunto de snapshots de backup e DR. Para economizar espaço no conjunto 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 preparação 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 e a recuperação de DR avaliam os tamanhos de registro típicos e o período de armazenamento deles e usam um disco maior, se necessário.

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

  • Período de retenção de backup de registro: a retenção de registro é definida separadamente do banco de dados associado. Ter taxas de retenção separadas permite manter informações de registro suficientes para cobrir todas as versões de snapshot de um banco de dados. O período de armazenamento de registros é uma configuração obrigatória.

  • Log Staging Disk Size Growth: define a porcentagem em que o disco de preparação em que os registros residem é aumentado automaticamente.

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

  • Compactar o backup de registro 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 do 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 os bancos de dados selecionados nela. Quando você protege a instância inteira, à medida que os bancos de dados são adicionados a ela, eles são incluídos automaticamente no próximo job de captura de backup e DR. Os bancos de dados em uma instância são pausados e capturados com um único plano de backup.

Se o banco de dados de backup e DR e a captura de registros estiverem ativados na política do plano de backup, todos os bancos de dados dessa instância poderão ser recuperados para o mesmo ponto no tempo. A recuperação e a progressão dos registros de todos os bancos de dados ou de um banco de dados específico em uma instância são realizadas na interface do usuário de 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 pausados e capturados 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 frequência. Para proteger automaticamente novos membros de um grupo de bancos de dados, crie e proteja esses bancos de dados em uma instância do SQL Server.

Como o nome sugere, os grupos de consistência garantem a captura e a recuperação consistentes em vários bancos de dados. Se a tecnologia de captura de banco de dados e de registro de backup e 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 a progressão dos registros de todos os bancos de dados ou de um único banco de dados em um grupo de consistência são realizadas na interface do usuário de backup e DR com uma única ação. Os membros de um grupo de consistência precisam residir na mesma instância.

Um grupo de consistência pode ser composto por:

  • 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 acelerar as operações de captura e acesso, os grupos de consistência consomem menos recursos do sistema (VDisks) do que a proteção de bancos de dados individualmente.

É possível validar a integridade do backup do banco de dados periodicamente montando uma imagem de backup em um servidor e executando a 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 tem a opção de 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 que é um banco de dados e uma VM totalmente funcional. A imagem pode ser migrada para um local novo e permanente.

Replicar dados do SQL Server

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

  • Reduz o uso geral da rede.

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

  • Criptografa dados usando o padrão de criptografia AES-256. A autenticação entre os aparelhos 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 Produção para espelho têm várias opções para replicar dados em um segundo dispositivo de backup/recuperação.

  • As políticas de produção para o OnVault usam um mecanismo reservado de backup e DR para transferir dados para o armazenamento de objetos.

Replicar registros

Quando a opção Enable Database Log Backup de uma política está definida como Enable, a configuração avançada Replicate Logs permite que os registros de transações do banco de dados do Microsoft SQL Server sejam replicados para um dispositivo de backup/recuperação remoto. Para que um job de replicação de registros seja executado, é necessário que haja uma política de replicação do StreamSnap incluída no modelo, além de um perfil de recurso que especifique um dispositivo de backup/recuperação remoto. Além disso, pelo menos uma replicação bem-sucedida do banco de dados precisa ser concluída. 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 ativada (não é o padrão), os registros são enviados para cada pool do OnVault especificado por uma combinação válida de política ou perfil de recurso do OnVault (por exemplo, O pool OnVault 1 selecionado na política e o pool OnVault 1 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 a DR podem apresentar instantaneamente uma cópia do banco de dados rolada para um ponto específico no tempo. A operação de reversão é especificada no console de gerenciamento.

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

Independentemente 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 repositório de dados NFS apresentado ao host ESXi.

Controle de acesso baseado em papéis

É possível controlar quais usuários têm acesso a dados, recursos de backup e DR e recursos. Os dados capturados podem ser marcados como sensíveis, e os usuários de backup e DR podem receber permissão de acesso a dados sensíveis.

Montagem

A função de montagem de backup e DR oferece acesso instantâneo aos dados sem mover dados. Cópias capturadas de bancos de dados podem ser avançadas usando a interface do usuário de backup e DR e montadas em qualquer servidor de banco de dados. O backup e a DR oferecem duas maneiras de montar um banco de dados do Microsoft SQL Server:

  • O mount de 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 fora da produção. As montagens de aplicativos virtuais são criadas pelo dispositivo de backup/recuperação e não exigem intervenção manual por administradores de banco de dados, servidor ou armazenamento. As montagens de aplicativos virtuais podem ser usadas para relatórios de banco de dados, análises, testes de integridade, 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 AlwaysOn do SQL.

  • A montagem padrão, também chamada de montagem direta, apresenta e disponibiliza os dados capturados do Microsoft SQL Server a 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 montar uma imagem e copiar os arquivos do banco de dados da imagem montada para o local original no servidor de banco de dados. As montagens diretas são detalhadas em Montar dados Microsoft SQL capturados.

LiveClones

Um LiveClone é uma cópia independente dos dados do Microsoft SQL Server que pode ser atualizada e mascarada antes de ser disponibilizada para os 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 fonte. O tempo necessário para concluir uma operação de clonagem depende da quantidade de dados envolvidos. As clones são detalhadas em Clonar bancos de dados do SQL Server.

Restaurações

Uma restauração reverte os dados de produção para um ponto especificado. As operações de restauração realmente movem dados. As operações de restauração geralmente são realizadas após uma corrupção massiva de dados. 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, ele precisa estar no modo de restauração. É possível restaurar o banco de dados no modo de restauração e, em seguida, encaminhar os registros para um ponto específico no tempo. Se você restaurar o banco de dados sem especificar Restore with no Recovery, o banco de dados será restaurado e colocado 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, monte os dados primeiro, conforme detalhado em Montar e migrar dados SQL.

Workflows para automatizar o acesso aos 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 cientes do aplicativo) funcionam bem para dados do Microsoft SQL Server que não precisam ser mascarados antes de serem apresentados. Uma cópia montada de dados pode ser atualizada manualmente ou automaticamente em uma programação. As montagens diretas permitem 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 atualizado manualmente ou de forma programada. É possível mascarar dados sensíveis em um LiveClone antes de disponibilizá-los aos usuários.

A combinação da captura de dados automatizados do Microsoft SQL Server do Backup e DR e o controle de acesso com fluxos de trabalho e os recursos opcionais de mascaramento de dados permite criar ambientes de autoprovisionamento. Os usuários podem provisionar os próprios ambientes quase instantaneamente.

Por exemplo, um administrador de 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 de produção capturados do Microsoft SQL Server como sensíveis e acessíveis apenas por usuários com os direitos de acesso adequados.

Depois que os direitos de acesso forem definidos e os dados forem capturados, o administrador poderá criar um fluxo de trabalho que:

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

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

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

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

Backup e DR com produtos de backup

Como cada vez mais empresas buscam acelerar o desenvolvimento de aplicativos usando bancos de dados de produção, o backup e a DR geralmente precisam coexistir com produtos de backup legados que funcionam 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, se essas práticas recomendadas forem seguidas.

O backup e a DR têm um método reservado de rastreamento de blocos de mudança para que as soluções de backup que usam SQL ou outros métodos de obtenção de backups não sejam afetadas por jobs de captura de dados de backup e DR programados.

Os jobs de backup podem ser muito intensivos em E/S. Eles podem ter durações longas e afetar o desempenho do banco de dados durante as janelas de backup. O backup e a DR minimizam o impacto durante os jobs, mas mesmo uma atualização incremental permanente no nível do bloco precisa gerar alguma E/S e levar um pouco de tempo.

Requisito Não programe o software de backup legado e o Backup e DR para executar jobs de uma maneira que permita sobreposições no tempo.
Prática recomendada Programe jobs de backup e DR do banco de dados para começar quando o software de backup legado for concluído. Não programe o software de backup legado para ser executado imediatamente após a conclusão de um job de backup e DR.
Motivo Se os jobs de backup legados e os jobs de backup e DR forem executados simultaneamente, isso poderá resultar em um impacto grave no desempenho do servidor de banco de dados, levando à instabilidade e possivelmente a 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 do banco de dados de forma periódica 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 não de produção em um ponto específico da origem (produção). Isso geralmente elimina a necessidade de capturar e gerenciar registros como parte de uma solução de backup e DR ágil.

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 realizado pelo software de backup legado. Não use o backup e a DR para proteger registros neste ambiente.
Motivo Se o sistema estiver configurado para gerenciar (capturar ou truncar(limpar)) os registros e o software de backup legado também estiver capturando e/ou truncando/limpando os registros, um ou ambos os sistemas poderão ter uma cadeia de registros incompleta, o que dificulta ou impossibilita a recuperação do banco de dados para um ponto específico no tempo.

A seguir

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

Outra documentação sobre 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, binários e arquivos de suporte do Microsoft SQL Server com backup e DR.

Confira mais informações em: