Recuperação e Prevenção de

Desastres em SQL

Trabalho realizado
por:

- Paulo Carvalho

- Roberto
Pinheiro
 Introdução

Recuperação de desastres é um processo que pode utilizar para

ajudar a recuperar informações de sistemas e dados, se ocorrer um
desastre.

Alguns exemplos de desastres incluem desastres provocados por

humanos (como um incêndio por exemplo) ou um desastre técnico
como uma falha de dois discos rígidos numa matriz redundante de
RAID.

Planeamento de recuperação de desastres é o trabalho que é

dedicado para preparar todas as acções que devem ocorrer em
resposta a um desastre. O planeamento inclui a selecção de uma
estratégia para ajudar a recuperar dados importantes. A selecção da
estratégia de recuperação de desastres adequada, depende dos
requisitos da empresa.
 Ferramentas de recuperação de BD’s e
Prevenção de Desastres

Failover clustering
O cluster para failover é uma solução de alta disponibilidade
fornecida pelo SQL Server 2000 Enterprise Edition que usa os serviços
de cluster fornecidos pelo Microsoft Windows® 2000 Advanced Server
ou Microsoft Windows 2000 Datacenter Server.

Ele é a melhor solução para failover simples, rápido e automático.

Utiliza dois servidores para oferecer redundância de hardware.
Considere a possibilidade de usar o cluster para failover como a
primeira opção para alta disponibilidade, em vez de log shipping e
replicação transacional.

O cluster para failover mantém pelo menos um servidor em espera

em um cluster do MSCS (Microsoft Cluster Service), em caso de falha
do servidor do centro de dados primário. O Windows 2000 Advanced
Server oferece suporte a clusters com dois servidores e o Windows
2000 Datacenter Server oferece suporte a clusters com até quatro
servidores. Quando o MSCS detecta a falha do servidor primário, ele
automaticamente inicia em um servidor em espera os recursos do
cluster que estavam sendo executados no servidor que falhou. Em
seguida, o MSCS redireciona todo o tráfego do cliente para o servidor
em espera. Você também pode efetuar o failover manualmente para
um servidor em espera. Com o cluster para failover, todas as
transações confirmadas estão sempre disponíveis através do servidor
em espera, após a falha do servidor primário.

Failover clustering é suportado pelos seguintes Sistemas

Operativos:

• Microsoft Windows NT 4.0, Enterprise Edition

• Microsoft Windows 2000 Advanced Server

• Microsoft Windows 2000 Datacenter Server

• Microsoft Windows Server 2003, Enterprise Edition

• Microsoft Windows Server 2003, Datacenter Edition

Estes S.O.’s incluem um component adicional chamado Microsoft
Cluster Service (MSCS). Para implementar failover clustering para o
SQL Server, é necessário instalar o MSCS.

Failover clustering, vantagens e desvantagens

Vantagens

• Temos alta disponibilidade de serviços. Failover clustering entra

em acção assim que o servidor primário falha.

Desvantagens

• É bastante dispendioso. A manutenção de dois servidores é

duas vezes mais cara que a manutenção de apenas um.

• Os servidores devem estar geograficamente perto. Se as várias

sucursais da empresa estão espalhadas à volta do globo, e os
diferentes clusters necessitam ser instalados nas várias
sucursais, toda a rede e estrutura de armazenamento de dados
necessária é muito diferente da usual. Como tal, apesar de
possivel, não é aconselhado o uso de servidores
geograficamente distantes.

• Não há protecção contra uma falha no(s) disco(s) rígido(s).

Database mirroring (Espelhamento da BD)

Database mirroring é uma solução por software com o objectivo de

aumentar a disponibilidade da BD. Com o DB Mirroring temos uma
cópia intacta da BD a trabalhar de forma síncrona com a BD original.
Isto é, assim que há uma alteração na BD principal, essa alteração é
feita ao mesmo tempo na BD de backup. Funciona como o Failover
Clustering mas com redundância de dados além de serviços. Permite
ainda que os servidores estejam geograficamente distantes.

Database mirroring, vantagens e desvantagens

Vantagens

• Aumenta a protecção dos dados.

• Aumenta a disponibilidade da BD.

Desvantagens

• A BD de backup deve ser idêntica à original. Por exemplo, todos

os objectos, logins e permissões devem ser iguais.

• Database mirroring implica a transferencia de informação entre

diferentes computadores pela rede. Como tal, a segurança na
transferência da informação é um factor a ter em conta ao
implementar esta solução.
Replicação transaccional Peer-to-peer
A replicação ponto a ponto fornece uma a solução, expandida e de
alta disponibilidade, para manter cópias de dados em várias
instâncias de servidor, também denominadas nós. Criada na base da
transacção replicacional, a replicação ponto a ponto propaga-se de
forma transaccional, de acordo com as alterações em tempo real.
Activa aplicativos que requerem operações expandidas de leitura
para distribuir as leituras de clientes em vários nós. Como os dados
são mantidos em todos os nós em tempo quase real, a replicação
ponto a ponto fornece redundância de dados, o que amplia a
disponibilidade de dados.

Replicação Transaccional Peer-to-Peer

Vantagens

• A performance de leitura da BD é melhorada pois podemos

servir-nos dos recursos de todos os nós que contêm replicações
da BD.

• A performance de “insert”, “update” e “delete” para toda a

topologia assemelha-se a uma topologia de apenas um nó visto
que as actualizações são automaticamente propagadas para
todos os nós.

Desvantagens

• Tecnologia apenas disponível para SQL Server 2005

Enterprise Edition e SQL Server 2008.

• Todas as BD´s participantes da topologia devem ter os mesmos

esquemas e dados.

• Há sempre alguma latência envolvida quando as alterações são

replicadas.

• Apenas proporciona detecção e resolução de conflitos em SQL

Server 2008.
Log shipping

O processo do log shipping é relativamente simples, são alguns

passos realizados nos servidores envolvidos no processo que fazem
todo o trabalho. Primeiro, é feito um backup dos dados do servidor
principal. Este backup é gravado fisicamente em uma pasta
compartilhada que é acessada por este e outros servidores. Os outros
servidores são chamados de secundários. Depois de ser feito o
Backup do banco, ele é copiado para uma pasta específica em cada
servidor secundário. Depois de copiado, o backup é restaurado. Um
servidor de monitoramento pode ser configurado e ele registrará
todos os passos do servidor principal e dos secundários. Se não
configurar o monitoramento, cada servidor registra suas próprias
ações. Este monitor registra os históricos, status dos backups e
restaurações, e pode disparar alerta se alguma operação agendada
falhar. O responsável pela configuração do log shipping pode
especificar quando serão feitos os backups, quando serão copiados
da pasta compartilhada e quando que serão restaurados nos
servidores secundários.

O envio de logs permite o envio automático de backups do log de

transações de um banco de dados primário de uma instância do
servidor primário para um ou mais banco de dados secundário em
outras instâncias de servidor secundário. Os backups de logs de
transação são aplicados individualmente aos bancos de dados
secundários. Uma terceira instância de servidor opcional, conhecida
como servidor monitor, registra o histórico e o status das operações
de backup e restauração e, opcionalmente, emite alertas se essas
operações não forem executadas como foram agendadas.
 Log Shipping, Vantagens e Desvantagens

Vantagens

• Podemos recuperar todas as alterações na BD, inclusive

qualquer objecto que tenha sido criado, como uma tabela ou
uma view. Inclui também alterações de segurança, como novos
utilizadores criados e alterações nas permissões.

• Podemos restaurar a BD muito mais depressa do que noutras

soluções possíveis.

Desvantagens

• A BD é inutilizável enquanto se faz o restauro, pois a BD fica em

modo exclusivo no servidor secundário durante um restauro.

• Não há um redireccionamento automático das aplicações

dependentes quando o servidor primário falha. O administrador
tem de redireccionar as aplicações manualmente uma a uma.
Replicação Transaccional
A replicação transaccional normalmente inicia com um “instantâneo”
dos objetos e dados da base de dados de publicação. Assim que o
instantâneo inicial é tirado, as alterações subsequentes nos dados e
as modificações no esquema efectuadas no Publicador geralmente
são distribuídas para o Assinante assim que ocorrem (quase em
tempo real). As alterações nos dados são aplicadas ao Assinante na
mesma ordem e dentro dos mesmos limites de transacção conforme
ocorreram no Publicador, por isso, dentro de uma publicação, a
consistência transaccional é assegurada.

A replicação transaccional é normalmente usada em ambientes do

tipo servidor para servidor e é apropriada em cada um dos seguintes
casos:

• Você quer que as alterações com incremento sejam propagadas

para os Assinantes à medida que ocorrem.

• O aplicativo requer baixa latência entre as mudanças de hora

feitas no Publicador, assim as mudanças chegarão ao
Assinante.

• O aplicativo requer acesso aos estados de dados intermediários.

Por exemplo, se uma linha muda cinco vezes, a replicação
transaccional permite que um aplicativo responda a cada
mudança (como accionar um gatilho), e não simplesmente uma
mudança de dados da rede na linha.

• O Publicador tem um volume muito alto de actividade de

inserção, actualização e exclusão.
Por padrão, os Assinantes de publicações transaccionais devem ser
tratados como somente leitura, porque as alterações não são
propagadas de volta para o Publicador. Porém, replicação
transaccional oferece opções que permitem actualizações ao
Assinante.

A replicação transaccional é implementada pelo Snapshot Agent, Log

Reader Agent e Distribution Agent do SQL Server. O Snapshot Agent
prepara os arquivos de instantâneo que contêm o esquema e os
dados das tabelas publicadas e os objectos do banco de dados,
armazena os arquivos na pasta do instantâneo e regista os trabalhos
de sincronização do banco de dados de distribuição no Distribuidor.

O Log Reader Agent monitoriza o log de transacções de cada banco

de dados configurado para replicação transaccional e copia as
transacções marcadas para replicação do log de transacções no
banco de dados de distribuição, que atua como uma fila confiável
para armazenar e avançar. O Distribution Agent copia os arquivos do
instantâneo inicial da pasta de instantâneo e as transacções contidas
nas tabelas do banco de dados de distribuição para os Assinantes.

As alterações incrementais feitas no Publicador fluem para os

Assinantes de acordo com a programação do Distribution Agent, que
pode ser executado continuamente para ficar com latência mínima,
ou em intervalos programados. Como as alterações nos dados devem
ser feitas no Publicador (quando a replicação transaccional for usada
sem as opções de actualização imediata ou actualizações em fila), os
conflitos de actualizações serão evitados. Por fim, todos os Assinantes
alcançarão os mesmos valores que o Publicador. Se as opções de
actualização imediata ou actualizações em fila forem usadas com a
replicação transaccional, as actualizações poderão ser feitas no
Assinante, e com a actualização em fila, poderão ocorrer conflitos.

Replicação Transaccional, vantagens e desvantagens

Vantagens

• Podemos ler a informação contida num assinante enquanto

fazemos alterações.

• As alterações são aplicadas com menos latencia do que com log

shipping.

Nota Esta vantagem pode não ser aplicável caso:

 o Os Distribuiton agents não estejam configurados como
Continuous.

o Os Distribuiton agents estejam parados por causa de

erros que possam ter ocorrido durante a distribuição.

Desvantagens

• Não distribui alterações de esquema ou de segurança na BD.

• Por norma, ao trocar de servidor, todas as configurações de

replicação são apagadas, como tal temos que as configurar
sempre que tal acontece.

• Em caso de desastre, o administrador tem de redireccionar as

aplicações manualmente uma a uma para o servidor assinante.

Backup e restore
Backup and Restore é uma importante ferramenta do SQL Server
que ajuda a proteger contra perdas de informação que tenha na sua
BD. Pode-se criar uma cópia da BD (backup) utilizando a ferramenta
Backup and Restore, e depois armazenar essa cópia num local
protegido de potenciais falhas que possam ocorrer no servidor que
corre o SQL Server. Se ocorrer uma falha de sistema ou corrupção dos
dados, podemos utilizar a cópia para repor, restaurar ou recrear a BD.

Ao criar um plano de recuperação de BD utilizando a ferramenta

Backup and Restore, tenha sempre em conta o quão importante a
informação é. Tenha sempre em conta também que restaurar uma BD
através de um backup, apenas restaura a BD até ao ponto em que se
fez o backup. Todas as alterações após a criação do backup, perder-
se-ão. Além disso o processo de restaurar uma BD pode ser
demorado e todas as aplicações dependentes dessa BD irão estar
paradas enquanto a BD não for restaurada.

Backup e restore, vantagens e desvantagens

 Vantagens

• Podemos fazer copias da BD para suportes de media

removíveis (discos rígidos, dvd’s, tapes, etc…) e assim proteger
a informação contra eventuais falhas no disco.

• Não dependemos de rede para implementar esta solução, como

noutras já apresentadas (failover clustering, log shipping,
etc…).

Desvantagens

• Ao fazer a cópia da BD não podemos fazer certas operações,

como criação de tabelas ou de index.

• Se ocorrer uma falha pode-se perder as alterações mais

recentes á BD.

• Em caso de falha tem que se restaurar manualmente a BD.

Utilizar tecnologia RAID, (redundância de discos rígidos)

A tecnologia RAID permite-nos criar uma redundância de disco rígidos

providenciando uma maior confiabilidade nos servidores, reduzindo o
tempo que possam necessitar de estar desactivados. RAID nível 0, 1,
e 5 são normalmente utilizados como medida de prevenção contra
perda de dados numa BD. Este tipo de tecnologia permite até a falha
e consequente substituição de um disco rígido sem ter que desligar o
respectivo servidor. No entanto em caso de falha múltipla dos discos
pode-se perder grande parte ou mesmo todos os dados da BD, como
tal é uma óptima tecnologia quando utilizada em combinado com
outras como a de Backup e Restore.

RAID, vantagens e desvantagens

Vantagens
 • Evita a perda de dados em caso de falha de um disco rígido.

Desvantagens

• Recuperar dados perdidos e substituir discos corruptos é um

processo que pode ser complicado e demorado.

• Em caso de falha múltipla de discos rígidos, pode-se perder

grande parte ou mesmo todos os dados da BD.
Protecção contra vírus. (programa anti-vírus)

Deve-se usar um programa anti-vírus para proteger os dados contra

vírus da Internet e de software que pode ser infectado.

Também devemos certificar-nos que o programa antivírus é

actualizado regularmente.

Utilizar um produto antivírus que actualiza o antivírus com a definição

crítica feita automaticamente é fundamental para um computador
protegido.

Usar o antivírus actualizado e procurar ameaças no disco rígido

regularmente é uma das medidas de segurança mais importante a
tomar, de forma a eliminar pequenas ameaças.

A instalação de uma firewall também é uma ferramenta importante

para a segurança da informação de forma a dificultar a vida a ataques
invasores.

Vantagens

• Protecção contra vírus e spywares;

• Protecção contra invasores;

Desvantagens

• Torna o processamento do computador/servidor mais lento;

Programas úteis

Em caso de ficar sem a informação nos discos rígidos, ou até mesmo

este ter uma avaria, é possível tentar recuperar com alguns
programas de recuperação de informação não garantido assim que
este recupere toda a informação.

Sendo dois deles:

• Active Undelete –

• Easy Recovery Professional

Bibliografia

http://databases.about.com/od/sqlserver/a/disaster.htm

http://msdn.microsoft.com/en-us/library/aa179423(SQL.80).aspx

http://databases.about.com/

http://support.microsoft.com/kb/822400/en-us

http://www.sql-server-performance.com/articles/dba/peer-to-
peer_replication_p1.aspx

http://msdn.microsoft.com/en-us/library/ms189852.aspx

http://www.sql-server-
performance.com/articles/clustering/mirroring_2005_p1.aspx

http://en.wikipedia.org

http://msdn.microsoft.com/en-us/library/ms187103.aspx

http://www.sql-recovery.com/

http://www.linhadecodigo.com.br/Artigo.aspx?id=1273