Back up de base de dados SQL

Por Luiz Paulo de Oliveira Santos

Data de Publicação: 05 de Março de 2007

Falaremos hoje sobre back ups de bancos de dados.

E a primeira coisa que vem a cabeça é a cópia incondicional do(s) arquivo(s) que armazena o banco de dados. Mas nem sempre isso representa a cópia real e segura das informações, principalmente se o banco estiver operante (operacional).

Alguns usuários simplesmente copiam o(s) arquivo(s) do banco de dados com o servidor ativo, e, inclusive com acessos concorrentes acontecendo, e, pensam que têm em mãos uma cópia segura da base de dados. Isso não é fato! Algumas vezes a cópia (denominada cópia sombra) até funciona, porém muitas vezes não!

Logo, para copiar um banco de dados deve-se seguir procedimentos recomendados pelo fabricante do banco. Cada banco possui particularidades no momento da cópia, logo, não há um procedimento único para cada banco.

E existem engines de back ups on-line para praticamente todos os bancos de dados, disponibilizados pelo fabricante ou por terceiros, e que farão realmente a cópia correta e confiável. Essa cópia é a mais recomendada pois não compromete o acesso à base de dados.

Sobre cópias podemos dizer que alguns bancos nos permitem gerar cópias COMPLETAS (FULL) e em alguns casos INCREMENTAIS e/ou DIFERENCIAIS. Desta forma poderemos efetuar cópias completas e de momento a momento cópias apenas com as diferenças desde o ultimo back up completo ou somente as diferenças desde o ultimo back up feito.

Além do momento do back up, e, do conteúdo das cópias, podemos ter diferentes tipos de cópias geradas:

- Back Up do sistema de arquivos.

- SQL Dump.

- Back Up On-line.

- Cópia para migração entre versões de SGBD.

Vamos por partes:

Back Up a nível de sistema de arquivos:

É um dos mais utilizados, para que seja confiável e integro sugere-se baixar o serviço de banco de dados antes de se efetuar a cópia. No UNIX é comumente gerado com TAR e no MS-Windows com o software de back up que acompanha o Sistema Operacional. Porém pode-se comumente efetuar uma cópia do banco ~V arquivo(s) para outra mídia. Informações como: obtuário, garbage collection, registros removidos, arquivos temporários, índices e outros arquivos também são levados junto, aumentando de maneira significativa o volume de informações.

É recomendado para situações onde necessita-se restaurar tudo, por exemplo num caso de crash de disco, ou troca de equipamento.

Outra forma pouco ortodoxa, mas bastante empregada é a geração de uma imagem binária do disco todo. Em caso de crash do disco é possível gerar o disco exatamente como estava antes do desastre acontecer. Porém a atualização da imagem é muito demorada e esse método torna-se impraticável.

SQL Dump:

O DUMP nada mais é que uma captura, um flash do banco no momento do back up, e em um formato que se possa facilmente acessar. Alguns bancos de dados geram DUMP em formato texto ASCII, que pode-se facilmente abrir com um editor de textos (vi, notepad ou mesmo o EDIT do MS-DOS), outros bancos geram DUMPs num formato que pode ser visualizado ou editado através de ferramentas. O DUMP nada mais é que uma representação completa do banco naquele momento. Em bancos de dados transacionais o DUMP deve ser gerado com cuidado pois de acordo com parâmetros pode-se ou não ter dados das ultimas transações ou transações não COMMITadas. É um formato de fácil e rápida importação.

Geralmente o DUMP é recomendado para situações onde o restore (restauração da informação) é de parte de uma tabela, ou mesmo, campo(s) de um registro, ou outra informação muito específica é necessária. Nesses casos o DUMP se mostra extremamente eficiente e prático.

Algumas ferramentas de back up classificam o DUMP de Cópia de Dados e Meta-Dados.

Back Up On-line:

É o método de cópia mais comum e mais empregado para salvar cópias de bancos de dados. Com esse tipo de cópia todos os usuários continuam a utilizar os bancos de dados normalmente, enquanto a cópia é confeccionada. Geralmente é copiado tudo que já foi COMMITado.

Cópia para migração entre versões do banco de dados:

A cópia de dados também é utilizada para a migração entre diferentes versões do banco de dados SQL.

Quando atualizamos o software do Sistema Gerenciador de Banco de Dados (SGDB) devemos verificar se a nova versão é capaz de entender e gerenciar a versão anterior. Caso não seja o método mais indicado é gerar uma cópia completa do banco na versão anterior e restaurar a base completa na versão atualizada, desta forma o banco gerado (novo) será 100% compatível com a nova versão pois foi criado por ela.

Esse procedimento também é indicado para remoção de garbage collection, obtuário e demais informações que se acumulam, devido algumas situações adversas, em alguns bancos de dados.

Outras informações que devem ser copiadas:

Funções definidas pelo usuário (UDF): As funções definidas pelo Usuário muitas vezes ficam armazenadas em outras pastas, e as vezes em outros discos, e também precisam ser copiadas no back up.

Triggers, Stored procedures, arquivos de configuração e demais arquivos adicionais também devem ser copiados.

Extremamente importante:

Mais importante do que fazer o back up é testar o back up feito. Muitos profissionais confiam cegamente naquela mensagem: ~SBack up realizado com sucesso!~T. E quando mais necessitam restaurar informações os ~Sproblemas~T acontecem. Então não basta ter um back up, deve ter um back up testado!

No próximo artigo estaremos falando de back up no PostgreSQL e em seguida no Firebird e por ultimo no MySQL. Gostaria de agradecer à Cristina Otsuka pelos dois artigos sobre back up no MySQL que já se encontram na coluna Bancos de Dados Free do Dicas-L.

Até lá.