Partilhar via

  • Artigo

Planejando a recuperação de desastres

Quando você está administrando um banco de dados SQL Server, a preparação da recuperação de desastres potenciais é importante. Um plano de backup e restauração testado e bem projetado para seus backups do SQL Server é necessário para recuperar seus bancos de dados depois de um desastre. Para obter mais informações, consulte Introdução às estratégias de backup e restauração no SQL Server. Além disso, para ter certeza de que todos os seus sistemas e dados poderão ser restaurados rapidamente para a operação regular se um desastre natural acontecer, você deve criar um plano de recuperação de desastres. Quando você criar este plano, considere cenários para tipos diferentes de desastres que poderiam afetar sua loja. Eles incluem desastres naturais, como incêndio, e desastres técnicos, como falha de dois discos em uma matriz RAID-5. Ao criar um plano de recuperação de desastres, identifique e prepare todas as etapas exigidas para reagir a cada tipo de desastre. É necessário testar as etapas de recuperação para cada cenário. Recomendamos que você verifique seu plano de recuperação de desastres, por meio de simulação de um desastre natural.

Quando você estiver projetando seu plano de backup e restauração, leve em consideração no planejamento de recuperação de desastres as suas necessidades específicas ambientais e empresariais. Por exemplo, suponha que aconteça um incêndio que destrua seu centro de dados 24 horas. Você tem certeza de que poderá recuperá-lo? Quanto tempo levará para fazer a recuperação e ter seu sistema disponível? Qual a quantidade de perda de dados que seus usuários poderão suportar?

O ideal seria seu plano de recuperação de desastres apresentar quanto tempo a recuperação levará e o estado do banco de dados final que os usuários podem esperar. Por exemplo, você poderia determinar que depois da aquisição do hardware especificado, a recuperação seria concluída em 48 horas, e os dados só seriam garantidos até o fim da semana anterior.

Um plano de recuperação de desastres pode ser estruturado de muitos modos diferentes e pode conter muitos tipos de informações. Os tipos de plano de recuperação de desastres incluem o seguinte:

  • Um plano para adquirir hardware.

  • Um plano de comunicação.

  • Uma lista das pessoas a serem contatadas se um desastre acontecer.

  • Instruções para contatar as pessoas envolvidas na resposta ao desastre.

  • Informações sobre quem possui a administração do plano.

  • Uma lista de verificação de tarefas exigidas para cada cenário de recuperação. Para ajudar a revisar como a recuperação de desastres progrediu, rubrique cada tarefa assim que for concluída e indique a hora de término na lista de verificação.

Modelos de recuperação do SQL Server

O SQL Server fornece três modelos de recuperação alternativos: simples, completo e com log de operações em massa. Modelo de recuperação é uma propriedade de banco de dados que controla o comportamento básico de operações de backup e restauração de um banco de dados. A seleção do modelo ideal de recuperação para cada um de seus bancos de dados é uma parte necessária do planejamento de estratégia de backup e restauração. A escolha do modelo de recuperação para um determinado banco de dados depende um pouco de seus requisitos de recuperação e disponibilidade. A escolha do modelo de recuperação, por sua vez, afeta as possibilidades para recuperação de desastres de um banco de dados.

Para obter uma introdução de modelos de recuperação, consulte Visão geral do modelo de recuperação.

Gerenciando mídia de backup

É recomendável que seu plano de backup inclua provisões para gerenciamento de mídia de backup, como a seguir:

  • Um plano de gerenciamento e rastreamento para armazenar e reciclar conjuntos de backups.

  • Uma agenda para substituir a mídia de backup.

  • Em um ambiente multiservidor, uma decisão para usar backups centralizados ou distribuídos.

  • Um meio de rastrear a vida útil da mídia.

  • Um procedimento para minimizar os efeitos da perda de um conjunto de backups ou uma mídia de backup (por exemplo, a perda de uma fita).

  • Uma decisão para armazenar conjuntos de backups interna ou externamente e uma análise de como isto afetará o tempo de recuperação.

Para obter informações sobre como o SQL Server usa dispositivos e mídia de backup, consulte Trabalhando com mídia de backup no SQL Server.

Executando um script de funcionalidade básica

Normalmente, você inclui um script de funcionalidade básica como parte de seu plano de recuperação de desastres para confirmar se tudo está funcionando como planejado. Um script de funcionalidade básica fornece uma ferramenta confiável para o administrador de sistema ou o administrador de banco de dados verificar se o banco de dados voltou para um estado operacional, sem depender de usuários finais para verificação.

Um script de funcionalidade básica é específico de aplicativo e tem muitas formas diferentes. Por exemplo, em um sistema de apoio à decisão ou de relatórios, o script poderia ser uma simples cópia de várias de suas consultas de relatórios importantes. Para um aplicativo OLTP (online transaction processing), o script pode executar um lote de procedimentos armazenados que executam instruções INSERT, UPDATE e DELETE. Por exemplo, um script de funcionalidade básica poderia ser tão simples quanto um arquivo .sql que envia instruções SQL em lote ao servidor do utilitário sqlcmd. Outro exemplo é o uso de um arquivo .bat que contém comandos bcp e sqlcmd.

Assegurando a preparação de desastres

Para certificar-se de que está pronto para desastres, recomendamos que você execute as atividades a seguir periodicamente:

  • Teste seus procedimentos de backup e recuperação completamente antes de ocorrer uma falha real. Os testes ajudam a garantir que você tenha os backups necessários para recuperação de várias falhas, que seus procedimentos estejam claramente definidos e documentados e que eles possam ser executados de forma tranqüila e rápida por qualquer operador qualificado.

  • Execute os backups de log de transações e banco de dados regulares para minimizar a quantidade de dados perdidos. Recomendamos que você faça backup dos bancos de dados do sistema e de usuários.

  • Mantenha logs de sistema de maneira segura. Mantenha registros de todos os pacotes de serviço instalados no Microsoft Windows e no SQL Server. Mantenha registros de bibliotecas de rede usados e o modo de segurança. Além disso, se o SQL Server estiver sendo executado na autenticação em modo misto (modo de autenticação SQL Server e Windows), registre a senha sa em um local seguro. Para obter mais informações, consulte Segurança e proteção (Mecanismo de Banco de Dados).

    Observação importanteImportante

    A autenticação do Windows é muito mais segura que a autenticação do SQL Server. Quando possível, você deverá usar a autenticação do Windows.

  • Em outro servidor, avalie as etapas que você precisa realizar para a recuperação de um desastre. Se for necessário, modifique as etapas conforme necessário para adequar ao ambiente de servidor local e teste as etapas modificadas.

  • Mantenha um script de funcionalidade básica para avaliar rapidamente a capacidade mínima.

Fazendo auditoria e reduzindo erros potencialmente calamitosos do usuário

Um dos cenários de recuperação mais desafiadores é a recuperação de um erro grave de usuário, como cancelar acidentalmente objetos de banco de dados. Esta seção lista ferramentas que podem ajudar na auditoria e, em alguns casos, na regulamentação de alterações nos bancos de dados.

  • Gatilhos DDL (linguagem de definição de dados)

    Estes gatilhos podem ser criados para auditar e regulamentar certas mudanças em seu esquema de banco de dados. Os gatilhos DDL acionam procedimentos armazenados em resposta a uma variedade de instruções DDL. Estas são as instruções básicas iniciadas com CREATE, ALTER e DROP. O escopo de um gatilho DDL é um banco de dados particular ou uma instância de servidor inteira. Para obter mais informações, consulte Compreendendo os gatilhos DDL.

  • Notificações de eventos

    As notificações de eventos são executadas em resposta a uma variedade de instruções DLL Transact-SQL e eventos de rastreamento do SQL e enviam informações sobre estes eventos para um serviço Service Broker.

    Podem ser programadas notificações de eventos em relação a muitos dos mesmos eventos capturados pelo rastreamento do SQL. Mas, em vez de criar rastreamentos, você pode usar as notificações de eventos para executar uma ação dentro de uma instância de SQL Server em resposta aos eventos. Como as notificações de eventos são executadas de forma assíncrona, estas ações não consomem nenhum recurso definido pela transação imediata. Para obter mais informações, consulte Notificações de eventos (Mecanismo de Banco de Dados).

    ObservaçãoObservação

    Nem todos os eventos DDL podem ser usados em gatilhos DDL. Alguns eventos são destinados apenas para instruções assíncronas e não-transacionadas. Por exemplo, um evento CREATE DATABASE não pode ser usado em um gatilho DDL. Você deverá usar notificações de eventos para tais eventos.

  • SQL Server Agente

    Este é um serviço Windows que executa tarefas administrativas agendadas, chamadas trabalhos. O agente SQL Server usa o SQL Server para armazenar informações do trabalho. Entre outras coisas, o SQL Server Agent pode executar um trabalho em resposta a um evento específico, como erros que têm um nível de severidade específico ou número de mensagem.

    Para obter uma introdução sobre o SQL Server Agent, consulte Automatizando tarefas administrativas (SQL Server Agent). Para obter mais informações sobre como usar o SQL Server Agent para eventos, consulte Monitorando e respondendo a eventos.

  • Rastreamento do SQL

    O rastreamento do SQL fornece procedimentos armazenados do sistema Transact-SQL para criar rastreamentos em classes de evento selecionadas pelo usuário em uma instância do Mecanismo de Banco de Dados do SQL Server. Estes procedimentos armazenados do sistema podem ser usados nos seus próprios aplicativos para criar rastreamentos manualmente. Para obter mais informações, consulte Apresentando o Rastreamento SQL.

    ObservaçãoObservação

    O SQL Server Profiler é uma interface gráfica do usuário para rastreamento do SQL de monitoramento de uma instância do Mecanismo de Banco de Dados ou Analysis Services. Para obter mais informações, consulte Usando o SQL Server Profiler.