A importância dos backups

Não é novidade que nada no mundo é perfeito e, obviamente, os bancos de dados não
são exceção. Seja por falhas no próprio SGBD (bugs), ou por fatores externos (sistema
operacional, hardware, faxineira, etc.), é imprescindível adotar uma política de backups
para se precaver de acontecimentos e surpresas indesejáveis.

O Firebird oferece dois métodos nativos de backup: o bom e velho gbak, e o mais
recente, nbackup. A diferença básica entre eles é que o gbak realiza sempre um backup
completo da base de dados, armazenando a estrutura do banco e os dados das tabelas. Já
o nbackup permite a realização de backups incrementais, sendo que os arquivos gerados
contêm cópias exatas das páginas do banco de dados. No backup é incremental, apenas
as páginas que foram alteradas desde o último backup de nível anterior são gravadas.

Uma diferença importante é que o gbak não armazena no arquivo de backup o “lixo”
que pode existir no banco, como versões temporárias e registros apagados, árvores de
índices, páginas de inventário de transações, etc. Já o nbackup, por fazer uma cópia das
páginas do banco, leva também todo o lixo junto, e qualquer outra coisa que esteja
gravada nelas. Tanto é verdade, que um backup de nível zero no nbackup terá
exatamente o mesmo tamanho do arquivo do banco de dados. É praticamente uma cópia
do arquivo, com apenas alguns bytes de diferença no header, indicando que é um
arquivo de backup. Já um backup gerado pelo gbak produz um arquivo geralmente
muito menor do que o banco de dados, pois todo o lixo e as árvores de índices são
descartados.

Mas se você pensa que backups servem somente para te salvar em alguma situação de
emergência, está enganado! Os backups podem ajudar também para manter a boa
“saúde” do banco de dados. Como? Vejamos:

• Resetando o contador de alterações dos objetos do banco. Cada objeto que

compõe o banco de dados (ex: tabela, triggers, procedure, etc.) pode ser alterado
até 255 vezes. Quando atingir este valor, o Firebird não permitirá que se altere o
objeto mais uma vez. Para resolver essa situação, somente através de um
backup/restore com o gbak. O banco restaurado terá os contadores reiniciados
(zerados).
• Desfragmentar o arquivo de banco de dados. Em um ambiente de uso real, os
dados de diferentes tabelas são inseridos no arquivo de forma não seqüencial.
Páginas vão sendo alocadas conforme a necessidade, o que acaba fragmentando
o arquivo, fazendo com que o acesso se torne mais lento, pois a cabeça do HD
tem que saltar mais e viajar por mais lugares para recuperar a informação
desejada. Fazendo um backup/restore, o novo arquivo gerado será praticamente
contínuo (obviamente, o quão contínuo depende da existência de espaço
sequencial livre no HD), zerando ou diminuindo muito a fragmentação, e
aumentando a performance.
• Balanceamento dos índices. O Firebird usa uma versão modificada do BTree
para montar as árvores de índices. Com o passar do tempo, as árvores tendem a
ficar desbalanceadas, fazendo que pesquisas que utilizem índices demorem mais
do que deveriam para retornar os dados. Quando um backup é restaurado pelo
gbak, um novo banco de dados é criado, sendo todos índices recriados, ficando
perfeitamente balanceados. Note que, também é possível reconstruir um índice,
 desativando e ativando o mesmo no BD, mas isso nem sempre é possível, como,
por exemplo, nos índices que estão associados às regras de integridade.
• Coleta de lixo. Ao se fazer um backup com o gbak, todas as tabelas do BD são
percorridas (lidas). Esse processo acaba disparando a coleta de lixo, marcando
todos os registros que não são mais utilizados para serem reaproveitados. Dica:
Quanto estiver fazendo um backup com a intenção de logo em seguida fazer um
restore, utilize o parâmetro –g durante o backup, instruindo o gbak para não
disparar a coleta de lixo. Geralmente, isso acelera consideravelmente o tempo
necessário para criar o backup. O ganho depende diretamente da quantidade de
lixo existente no banco.

Fique atento, no entanto, que a única forma de se certificar que um arquivo de backup
gerado pelo gbak está OK e poderá ser restaurado quando necessário, é fazendo um
restore nele. Um exemplo muito comum de arquivo de backup que não poderá ser
restaurado, é quando alguém alterou diretamente as tabelas de sistema do Firebird,
fazendo com que campos que aceitavam null passassem a ser not null, e esquecendo de
colocar valores nos campos dos registros que já existiam. Ao se tentar restaurar o
backup, o processo vai falhar.

Uma forma pouco conhecida de se fazer um backup/restore em um único passo é:

GBAK -B -G –user SYSDBA –pas xxxx C:\BD.FDB stdout | GBAK -C –user

SYSDBA –pas xxxx stdin C:\BD_BACKUP.FDB

A linha de comando acima faz com que o gbak desvie a saída para a stdout (ao invés de
um arquivo), redirecionando para a stdin. Ou seja, o comando acima não produz um
arquivo de backup, mas sim um banco de dados operacional (BD_backup.fdb).
Qualquer problema durante o processo retornará um erro imediatamente, ou seja, se
nenhum erro ocorreu, você pode ter certeza que o banco restaurado está ok.

É altamente aconselhável NUNCA sobrescrever um banco de dados existente durante o

processo de restore. Primeiro, restaure usando um nome temporário. Se tudo deu certo,
apague o arquivo do BD e renomeie o recém-restaurado usando o nome correto.
Certifique-se também de que não há conexões ativas no banco de dados quando for
substituí-lo por um novo, especialmente se estiver usando o Firebird no Linux. Para
fazer o backup, seja com o gbak ou com o nbackup, não é necessário acesso exclusivo
no banco de dados.

Se estiver usando o nbackup para fazer backups incrementais, tenha certeza de

armazenar os arquivos dos diferentes níveis de backup em um local seguro. Se você
perder qualquer arquivo de nível intermediário, só conseguirá restaurar o backup até o
nível anterior ao arquivo perdido. Certifique-se também de estar usando a versão mais
recente do Firebird, pois algumas versões mais antigas traziam um nbackup com vários
bugs.

Para ter uma visão geral e saber como utilizar o gbak e o nbackup, recomendo a leitura
do recém produzido manual do gbak, em http://www.firebirdsql.org/manual/gbak.html
e o do nBackp em http://www.firebirdsql.org/manual/nbackup.html, além de outros
artigos e livros disponíveis.
Este artigo mostrou que o processo de backup tem papel importante, não só como
garantia contra catástrofes, mas como parte do processo de manutenção do banco de
dados. Tão importante quanto fazer o backup, é se certificar que o backup gerado pode
ser restaurado.

Up the Irons!
Carlos H. Cantu
blog.firebase.com.br
www.firebase.com.br

http://www.firebase.com.br/fb/artigo.php?id=2204