Backup e DR para Microsoft SQL Server em um dispositivo de backup/recuperação

Capturar dados do SQL Server

O Backup e DR permite 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 preparo. Os snapshots no disco de preparo permitem que o dispositivo de backup/recuperação mantenha dados históricos.

Preparar para fazer backup de dados do Microsoft SQL Server

A preparação para fazer backup de 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ítica 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 momento específico ao avançar 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 preparo é criado e montado automaticamente em um servidor.

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

  • O disco de preparo é desmontado do servidor.

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

Capturar registros do 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. Ele 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 de registros do banco de dados é definida em minutos, e a frequência com que os registros são capturados não pode exceder a frequência com que o banco de dados associado é capturado. Por exemplo, se a frequência de captura do 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. Com períodos de retenção separados, é possível 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 forem mantidos por sete dias, será possível definir a retenção de registros para abranger todos os sete dias. Neste exemplo, um único banco de dados capturado pode ser selecionado, e os registros dele podem ser avançados durante todo o período.

Os registros do banco de dados são preparados em um único disco de preparo 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 de backup/recuperação remoto. É possível usar os registros no site remoto para qualquer banco de dados dentro do intervalo de retenção dos registros replicados.

Redimensionar o disco de preparo 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. Ele é chamado de disco de preparo de registros e é separado do armazenamento gerenciado pelo servidor de origem. No mínimo, o Backup e DR avalia os tamanhos de registro típicos e o período de armazenamento e usa um disco maior, se necessário.

Para gerenciar com mais eficiência e eficácia 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. 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.

  • Crescimento do tamanho do disco de preparo de registros: define a porcentagem de crescimento automático do disco de preparo em que os registros residem.

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

  • Compactar 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, é possível capturar toda a instância ou bancos de dados selecionados dentro dela. Quando você protege a instância inteira, os bancos de dados adicionados à instância 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 desativados e capturados junto 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 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.

Grupos de consistência de captura

Um grupo de consistência é um grupo de bancos de dados que são desativados 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 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 indica, os grupos de consistência garantem a captura e a recuperação consistentes em um momento específico em vários bancos de dados. Se a tecnologia de captura de banco de dados e de registros do 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 momento. A recuperação e o avanço dos registros de todos os bancos de dados ou de bancos de dados individuais 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 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 protegida, a GO segue o nó SQL ativo em um cluster. Os jobs de proteção continuam em execução 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 individual de bancos de dados.

É possível validar a integridade do backup do banco de dados periodicamente montando um 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 pode capturar o volume de inicialização da VM. Quando o volume de inicialização de uma VM é capturado junto com os bancos de dados, é possível apresentar um backup que é um banco de dados e uma VM totalmente funcionais. O backup pode ser migrado 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 para fins de recuperação, recuperação de desastres ou teste ou desenvolvimento. A replicação de dados há muito tempo é um inibidor do gerenciamento eficiente de dados em um ambiente geograficamente distribuído. A replicação de Backup e DR resolve esses problemas com uma 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 os dispositivos de backup/recuperação é realizada usando certificados de 1.024 bits.

A replicação é controlada pelas políticas do 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 de Backup e DR para transferir dados para o repositório de objetos.

Replicar registros

Quando a opção Ativar backup de registro do banco de dados de uma política está 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 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, e pelo menos uma replicação bem-sucedida do banco de dados precisa ser concluída primeiro. Em seguida, use os registros no site remoto para qualquer backup 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 local e remoto. 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 é 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 um do OnVault selecionado na política e o pool um 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 completo, o Backup e DR pode apresentar instantaneamente uma cópia do banco de dados avançada para um momento específico. A operação de roll forward é especificada no console de gerenciamento do dispositivo.

Para bancos de dados do Microsoft SQL Server que usam o modelo de recuperação básico, o Backup e DR pode apresentar instantaneamente qualquer backup do banco de dados que não tenha ultrapassado o 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 aos dados, aos recursos de Backup e DR e aos recursos. Os dados capturados podem ser marcados como sensíveis, e os usuários do Backup e DR podem receber permissão de acesso a dados sensíveis.

Suportes

A função de montagem do Backup e DR fornece acesso instantâneo aos dados sem movê-los. As cópias capturadas de bancos de dados podem ser transferidas usando a interface do usuário do Backup e 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 não relacionado à produção. As montagens de aplicativos virtuais são criadas no dispositivo de backup/recuperação e não exigem intervenção manual de 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 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, 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, é possível ativar um backup e copiar os arquivos do banco de dados do backup ativado 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 no conjunto de dados mais recente sem precisar gerenciar manualmente os dados 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 específico. As operações de restauração movem os 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, 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 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 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 com Application Awareness) 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 que você acesse instantaneamente os dados capturados do Microsoft SQL Server sem movê-los.

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

Combinar a captura de dados automatizada 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 provisionamento automático. 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 capture 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 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.

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

Backup e DR funcionando com produtos de backup atuais

Como cada vez mais empresas buscam acelerar o desenvolvimento de aplicativos usando bancos de dados de produção, o Backup e DR geralmente precisa coexistir com produtos de backup legados que funcionam nos mesmos ambientes de banco de dados de produção. O Backup e DR pode 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 DR tem um método próprio de rastreamento de blocos de alteração. 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 programados de captura de dados do Backup e DR.

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 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 levar um pouco de tempo.

Requisito Não programe o software de backup legado e o Backup e DR para executar jobs de modo que haja sobreposição de tempo.
Prática recomendada Programe os jobs de banco de dados do Backup e DR para começarem em um horário em que o software de backup legado já tenha terminado. Não programe o software de backup legado para ser executado imediatamente após a conclusão normal 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 sério 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 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 que não é de produção em um momento específico 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 realizado pelo software de backup legado, não use o Backup e DR para proteger os registros nesse ambiente.
Motivo Se o sistema estiver configurado para gerenciar (capturar ou truncar/limpar) registros, e o software de backup legado também estiver capturando e/ou truncando/limpando registros, um ou ambos os sistemas podem acabar com uma cadeia de registros incompleta, dificultando ou impossibilitando a recuperação do banco de dados para um momento específico.

Outras documentações 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 do Microsoft SQL Server com o Backup e DR. Encontre mais informações em:

A seguir

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