Artigo SQL Magazine 44 - Técnicas de backup e recuperação de dados em MySQL

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (0)  (0)

Artigo da Revista SQL Magazine - Edição 44.

Clique aqui para ler todos os artigos desta edição

Banco de Dados

 

Técnicas de backup e recuperação de dados em MySQL

 

A utilização de um SGBD tem se tornado cada vez mais popular para as mais variadas aplicações. Neste contexto, a confiabilidade dos dados torna-se crucial, uma vez que todo o processo de gestão passa a depender cada vez mais destas bases de dados. Entretanto, em ambientes de produção podem ocorrer problemas de natureza variada que podem comprometer este armazém de dados, tais como falhas de hardware, software ou até mesmo execução de comandos indesejados por parte dos usuários – DROP DATABASE – por exemplo.

Com o intuito de evitar a perda de informações nestas situações de desastres é preciso manter uma cópia de segurança dos dados, conhecida como backup, para que este repositório possa ser restaurado completamente sem causar prejuízos para a instituição que o utiliza.

O objetivo deste artigo é discutir os principais fatores relacionados à execução de uma rotina consistente de backup e apresentar as principais ferramentas existentes no MySQL para que se tenha uma cópia íntegra de suas informações. Além disto, serão apresentadas técnicas de recuperação de dados a partir do backup de forma a garantir que toda a informação existente no momento do desastre seja restaurada sem haver comprometimento da integridade ou até mesmo perda de dados.

 

Procedimento de backup de dados

Ao se executar uma rotina para copiar as informações armazenadas pelo SGBD é preciso ter alguns cuidados para que se tenha uma imagem dos dados que seja fiel ao dado original e, portanto, confiável. Sabemos que em sistemas em produção a base de dados possui um comportamento dinâmico e a cada fração de tempo pode se encontrar em uma situação distinta. Neste caso, o backup deve espelhar coerentemente a situação dos dados em um ponto qualquer do tempo. A Figura 1 ilustra a evolução de uma base de dados e o resultado da execução de uma cópia consistente.

 

Figura 1. Evolução da base de dados durante o procedimento de backup

 

Percebe-se a partir da análise da Figura 1 que o procedimento de cópia não é discreto, ou seja, ele se estende por um período de tempo. Assim, a rotina de cópia de dados deve garantir uma imagem da base de dados que reflita a sua situação no momento em que o backup se iniciou (T1) ou que contenha a posição dos dados ao término do procedimento (T2). Neste ponto, surge uma questão fundamental que é determinar se a base de dados copiada estará ou não acessível aos seus usuários no momento em que a cópia de segurança está sendo executada.  Sob esta ótima é possível proceder de três formas distintas:

1.      Fazer a cópia com o SGBD em execução, não impondo nenhuma restrição de acesso aos dados, conhecido como backup online.

2.      Parar a execução do SGBD de forma que não haja nenhum acesso aos dados durante a execução da cópia de dados.

3.      Impor restrições de escrita aos dados com o uso de locks (bloqueios), permitindo apenas o acesso de leitura às informações durante a execução da rotina de backup.

 

A opção número 1, que é o backup online, é fundamental para aplicações onde não há a possibilidade de limitar ou interromper o acesso ao sistema. Neste caso, a estratégia de backup deve conter mecanismos para realizar uma espécie de congelamento dos dados, refletindo a situação da base de dados no momento em que foi iniciada no seu término. Isto se deve ao fato de que em um SGBD existem informações relacionadas que por regras de normalização ficam armazenadas em tabelas distintas. Neste caso, se durante a cópia há uma transação em andamento e esta realiza uma alteração nestas relações, dependendo da ordem em que as tabelas são copiadas, pode-se gerar uma imagem incorreta da base de dados - copiar os itens de uma nota fiscal inexistente, por exemplo. Desta forma, o backup não poderá ser utilizado em caso de falhas, uma vez que não há consistência das informações nele armazenadas.

A segunda opção de backup garante que a base de dados estará consistente uma vez que não haverá nenhum acesso aos dados durante a cópia, dado que o SGBD não estará em execução. Esta solução pode ser utilizada apenas nas aplicações onde o sistema não opera 24 horas por dia, por isto não se aplica a todos os contextos.

Finalmente, a terceira opção pode ser utilizada caso o sistema não possa ficar completamente fora do ar, mas que permita uma interrupção de apenas uma parte de suas funcionalidades. Por exemplo, em sistemas onde há um elevado número de acessos de leitura e as atualizações são esporádicas, pode-se aplicar os mecanismos de locks para garantir que não haverá escrita durante a cópia dos dados. Assim, não há interrupção completa do sistema, mas garante-se que haverá ao final do backup uma imagem coerente dos dados que poderá ser utilizada em casos de falhas do sistema.

 

Backup lógico versus backup físico

Uma vez definida a estratégia que será adotada para realização da cópia dos dados, deve-se definir quais os tipos de informações serão copiadas. Neste aspecto, podem-se utilizar duas formas de backup, que são o arquivamento apenas das informações armazenadas pelo SGBD, conhecida como backup lógico, ou copiar toda a estrutura de arquivos e diretórios gerados pelo mesmo, conhecida como backup físico."

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?