Backup com Gbak de Hora em Hora [RESOLVIDO]

rmonteiraum
(usa CentOS)

Enviado em 27/12/2010 - 16:08h

Prezados,
Sou novo no mundo linux e ainda não consegui entender algumas coisas em relação ao backup com o firebird.
Atualmente, tenho um servidor rodando firebird 2.1 SServer com dois bancos distintos.
Preciso fazer backups de hora em hora, utilizando o gbak e compactando-os no formato GZ, bem como faz o Fibs no windows.
Além de apagar os backups antigos (ex: manter apenas os últimos 30 dias)


Minha estrutura de instalação onde se encontra o gbak, gfix, etc, está em /usr/lib64/firebird/bin-superserver e meus dois arquivos que desejo "backupear" estão em /home/sistema/empresa1.gdb e /home/sistema/empresa2.gdb

Hoje, utilizo a seguinte rotina de backup, que apanhei no link "http://explicandoati.blogspot.com/2009/07/script-de-backup-do-firebird-em-centos.html" onde eu alterei os locais do gbak e das bases de dados.

Se alguém puder me ajudar, ficarei muito grato, além de ser a oportunidade de um dos colegas que que detém esta informação e que sabem realmente fazer, compartilharem conosco este conhecimento valioso.

Um Forte Abraço,
Raphael Monteiro

m4tri_x
(usa Ubuntu)

Enviado em 27/12/2010 - 16:44h

Boa tarde,

/caminho/do/gbak -G -B -Z -V -T -user SYSDBA -pass masterkey empresa1.gdb bkempresa1.gdb
/caminho/do/gfix -M -I -user SYSDBA -pass masterkey


cara não sei se isso vai te ajudar mais a sintax de um sistema de backup que tenho aqui é assim...
porém não entendo do fbserver e nem gosto mto para falar a verdade... espero que ajude... []'s

rmonteiraum
(usa CentOS)

Enviado em 28/12/2010 - 04:39h

Em cima do sugerido pelo link que mecionei, consegui juntamente com um usuário de irc da freennode.org, "desembolar" a brincadeira.

Ficou mais ou menos assim:
####################

#!/bin/bash
#usuário do BD
login="SYSDBA"
# senha do usuário
senha="masterkey"
#caminho da sua base de dados
dir="/home/empresa1"
# data atual, dia, mês ano, do backup para ser concatenada no arquivo backup
data=`date +%d%b%y-%H%M` #neste exemplo, gera a data assim: 22Dez10-0244
# pasta + arquivo do BD
banco="$dir/BAR.GDB"
# pasta e arquivo de backup
backup="$dir/BACKUP/BAR/$data.gbk" #gera o arquivo de backup na pasta BAR com o nome = a data.
clear
# Imprime o nome do arquivo de backup
echo "Iniciando backup de $banco."
# Executa gfix para verificar a integridade
# executa o comando gfix para verificar a integridade do banco.
echo "Verificando a integridade dos dados..."
/usr/lib64/firebird/bin-superserver/gfix -v -f -user $login -password $senha $banco
echo "Integridade do base da dados $banco ok!"

echo "Validando os dados e eliminando fisicamente registros deletados..."
/usr/lib64/firebird/bin-superserver/gfix -sweep -user $login -password $senha $banco
echo "Validação ok!"
# Realiza o backup
# executa o gbak para fazer o backup e gera o nome do backup com o nome do banco + a data
echo "Realizando o Backup para o Arquivo: $backup ..."
/usr/lib64/firebird/bin-superserver/gbak -b -user $login -password $senha $banco $backup

#Compacta o Backup
echo "Compactando o Arquivo de Backup ..."
gzip -v $backup
echo "Arquivo compactado com sucesso!"
#usando o tar, nao deu certo, alem de que, o formato .GZ é requerido pelo fabricante do software. Alem de que, não precisei gerar uma rotina para apagar o backup original, sendo que o gzip ZIPA e apaga o original.

#Removendo arquivos antigos
echo "Removendo backups com mais de 30 dias"
find /home/empresa1/BACKUP/BAR/ -ctime +30 -exec rm -rf {} \;
echo "Backups antigos removidos com sucesso!"
echo "Backup realizado com sucesso!"

##############

O único inconveniente, é q tenho dois bancos no mesmo servidor e fiz a mesma rotina, mudando os caminhos e nomes dos bancos. E aí, os dois rodam juntos no cron.hourly

pelo menos, penso q seja assim, os dois rodam o backup ao memso tempo, podendo causar lentidao aos usuários do banco.

Alguma sugestão?

m4tri_x
(usa Ubuntu)

Enviado em 28/12/2010 - 08:42h

Bom se os 2 estiverem rodando juntos, (Não tenho certeza de que funciona assim o cronta.hour), você pode colocar o segundo script sendo chamado pelo primeiro na ultima linha... Dai quando o primeiro finalizar ele chama o segundo...
Se você quiser inserir um timer para aguardar alguns segundos coloca assim:

script1
sleep 50;
/caminho/do/script2


[]'s

rmonteiraum
(usa CentOS)

Enviado em 02/01/2011 - 23:54h

Fiz o sugerido.

criei uma tarefa backup.sh no cron.hourly, que chama o primeiro script e dá uma pausa de 5 segundos, chamando o segundo.

Ao que me parece, tá dando certo. Exceto que agora estou enfrentando paradas súbitas do firebird, pelo menos uma vez por dia.

Acho que é o GFIX que está dando pau, pois sempre que rodo o script, tenho a seguinte resposta:

Verificando a integridade dos dados...
bad parameters on attach or create database
-secondary server attachments cannot validate databases

m4tri_x
(usa Ubuntu)

Enviado em 03/01/2011 - 08:31h

Bom dia,

Você está executando backups/correções no banco principal(em produção) quando todos estão usando?
Se sim, não sei se o firebird permite isso! Eu executo essas rotinas no backup que realizo durante a madrugada, nunca tive problemas com isso. Meu script começa a meia noite, faz uso do gfix para correção do banco e em seguida o gbak para armazenar o banco em um hd externo...


[]'s

dastyler
(usa Fedora)

Enviado em 03/01/2011 - 09:21h

Olá rm!!

Eu postei um script pronto de backup do Firebird há algum tempo. Accredito que pode ser adaptado para as suas necessidades sem maiores problemas:

http://www.vivaolinux.com.br/script/Backup-do-Firebird-por-data-via-rede-ou-local


Tem inclusive variaveis de shell que jogam data e hora no nome do arquivo. Agora quanto a gerra os tar.gz dos arquivos, basta adicionar o comando tar -czvf na parte do script que voce quer que gerar o arquivo compactado seguindo a lógica do script.
Hoje não trabalho tanto com FB, mas até hoje ainda me serve para faezr backups de pequenos sistemas.

[]´s

rmonteiraum
(usa CentOS)

Enviado em 05/01/2011 - 19:06h

Boa noite.

*m4tri_x*
Realmente, preciso fazer backup da base de dados com os usuários conectados, em banco de produção online.

No win, o Fibs desempenha esta tarefa, porém, notei que log dele gerava o mesmo erro.

Entrei em contato com o fabricante do software que acessa a base de dados e ele acabou confirmando que a opção de fazer manutenção na base de dados enquanto realiza o backup, deve ser desativada pois pode levar ao desligamento da base de dados e consequentemente, a desconexão dos usuários.

*dastyler*
O Script que eu postei, funciona bem.
O problema "era" fazer o backup em "tempos" diferentes para não sobrecarregar o processador ( o que descobri ser uma besteira, já que eu poderia fazer uns 10 backups ao memso tempo que o Core2Quad Xeon nem sentiria cócegas. testei... rsrs)

De qualquer forma, o m4tri_x sugeriu um sleep na execução do script e por cautela, apliquei a sugestão. Tá rodando show.


Voltando a linha de tempo do forum, o problema agora "era) (denovo) a desconexão súbita dos usuários e desligamento da base de dados. Resolvi, desabilitando a execução do GFIX durante o backup.

Aí sim, vem o problema.

Faço o backup com o gbak, normal, sem corrigir, limpar, fazer manutenção na base, etc.
No script acima, adicionei alguns parametros e ficou assim:
# /usr/lib64/firebird/bin-superserver/gbak -b -t -g -co -user $login -password $senha $banco $backup -y $dir/BACKUP/LOG/bar$data3.log -v

Blz, tá fazendo o backup, gerando log do backup, etc...

Mas, quero fazer a manutenção da base.

Coloquei "tico e teco" pra trabalhar e cheguei a uma conclusão que, na lógica, funciona, mas como sou novato em sistemas GNU/Linux, decidi compartilhar com vocês a minha idéia.

No script q postei anteriormente, a idéia é:
############
1-Iniciar o backup copiando a base de dados em uso;
# cp $banco /BACKUP/$data

2-Verificar a integridade da base da dados copiada para a pasta /BACKUP com o gfix;
# /usr/lib64/firebird/bin-superserver/gfix -v -f -user $login -password $senha /BACKUP/$data

3-Validar a base da dados com o gfix;
# /usr/lib64/firebird/bin-superserver/gfix -sweep -user $login -password $senha /BACKUP/$data

(enfim, o backup)
4-Realizar o backup;
# /usr/lib64/firebird/bin-superserver/gbak -b -t -g -co -user $login -password $senha /BACKUP/$data $backup -y $dir/BACKUP/LOG/bar$data3.log -v

5-Compactar a base que recebeu manutenção e foi backupeada
# gzip -v $backup

6-Remover os backups com mais de 30 dias;
find /home/empresa/BACKUP/BAR/ -ctime +30 -exec rm -rf {} \;

7-Remover a base de dados que foi copiada no início do script
rm /home/empresa/BACKUP/BAR/$data rm -rf

##############

Pergunta:
1- Posso copiar a base no meio de um acesso ou gravação na base?

2- Se sim, vai dar certo. Se não, alguma sugestão?

Abraços

rmonteiraum
(usa CentOS)

Enviado em 05/01/2011 - 19:34h

Segue abaixo o acript alterado conforma as mudanças que previ acima:

#!/bin/bash
#usuário do BD
login="SYSDBA"
# senha do usuário
senha="masterkey"
#caminho da sua base de dados
dir="/home/empresa"
# data atual, dia, mês, ano e hora para ser concatenada no arquivo backup
data=`date +%d%b%y-%H%M`
# data para ser exbida na execução do script
data2=`date +%c`
#data para ser adicionada ao LOG do backup
data3=`date +%d%m%y-%H%M`
# pasta + arquivo do BD
banco="$dir/BAR.GDB"
# pasta e arquivo de backup
backup="$dir/BACKUP/BAR/$data.gdk"
clear
# Início do Script de backup
echo "************* Iniciando backup em $data2 *************"
echo "**** Copiando base de dados para pasta de backup ****"
cp $banco /BACKUP/$data #sem o gdk mesmo

# Executando o gfix para verificar a integridade do banco.
echo "Verificando a integridade dos dados..."
/usr/lib64/firebird/bin-superserver/gfix -v -f -user $login -password $senha $dir/BACKUP/$data
echo "Comando executado com sucesso!" # é só pra saber onde parou o backup, caso pare
echo "******************************"
echo "Validando os dados e eliminando fisicamente registros deletados..."
/usr/lib64/firebird/bin-superserver/gfix -sweep -user $login -password $senha $dir/BACKUP/$data
echo "Comando executado com sucesso!"
# executa o gbak para fazer o backup e gera o nome do backup com o nome do banco + a data
echo "Realizando o Backup para o Arquivo: $backup ..."
/usr/lib64/firebird/bin-superserver/gbak -b -t -g -co -user $login -password $senha $dir/BACKUP/$data $backup -y $dir/BACKUP/LOG/bar$data3.log -v
# o backup é gerado na pasta BAR, mas poderia continuar sendo na pasta /BACKUP. Por "preguiça", deixei assim, já que o processo não vai demorar mais ou menos por conta disso.
#Compacta o Backup
echo "Compactando o Arquivo de Backup ..."
gzip -v $backup #-v é no modo verbose, mas como é um Quad Zeon, nem mostra :P
echo "Arquivo compactado com sucesso!"

#Removendo arquivos antigos
echo "Removendo backups com mais de 30 dias"
find /home/empresa/BACKUP/BAR/ -ctime +30 -exec rm -rf {} \;
echo "Backups antigos removidos com sucesso!"
echo "Backup realizado com sucesso!"
echo "Removendo Logs com mais de 30 dias"
find /home/empresa/BACKUP/LOG/ -ctime +30 -exec rm -rf {} \;
echo "Logs antigos removidos com sucesso!"
echo "Removendo cópia da base de dados"
rm -f /home/empresa/BACKUP/$data
Echo "backup realizado com sucesso"

m4tri_x
(usa Ubuntu)

Enviado em 06/01/2011 - 08:49h

Bom dia,

Raphael, não entendo muito do firebird porém dei uma lida na internet e peguei uma informação que parece ser interessante para você:

Dê uma olhada no post do Fabiano Moura.
http://comments.gmane.org/gmane.comp.db.firebase.portuguese/92695

Em resumo ele diz que o Firebird é um dos poucos bancos que permitem efetuar a copia do banco em tempo real. Porém pelo comando Gbak, então sugiro que não utilize o comando cp, mesmo que seja possivel depois resgatar o banco de dados eliminando os registros errados que foram copiados é um procedimento arriscado.

Você pode usar o Gbak no lugar do cp e em seguida passar o gfix no banco copiado pelo Gbak... Ao final do procedimento você pode executar comandos como:

#lsof -i TCP:3050

para ver a quantidade de conexões com o banco...

#iotop

para monitorar a atividade do disco

são comando uteis que podem identificar o motivo de estar travando desse jeito, pois dei uma olhada na internet, e há outras pessoas que fazem o mesmo procedimento que você, praticamente com os mesmos comandos sem problema nenhum...

[]'s

rmonteiraum
(usa CentOS)

Enviado em 06/01/2011 - 12:33h

Seria o caso de fazer um script usando o GBAK para "backupear" o banco online para uma pasta chamada BACKUP, alterando o nome do banco backupeado para Ex: BAR.gdk, em seguida, restaurar este banco na mesma pasta de backup, , mas com nome diferente Ex: temporario.gdb, mantendo-o offline, executar o GFIX para corrigir possíveis erros e limpar o banco, executar novamente o GBAK para "backupear" a base que recebeu manutenção e compactar a base backupeada?

Seria algo do tipo:
***************************************************************
1º Backupear o banco de produção para a pasta backup
# /usr/lib64/firebird/bin-superserver/gbak -b -t -g -co -user $login -password $senha $dir/BACKUP/$data $dir/BACKUP/BAR.gdk

2º Restaurar o banco para a mesma pasta de backup, com o nome temporario.gdb
# /usr/lib64/firebird/bin-superserver/gbak -create -v -inactive $dir/BACKUP/BAR.gdk $dir/BACKUP/temporario.gdb

3º Executar a verificação de integridade do banco restaurado
# /usr/lib64/firebird/bin-superserver/gfix -v -f -user $login -password $senha $dir/BACKUP/temporario.gdb

4º Executar a validação dos dados
# /usr/lib64/firebird/bin-superserver/gfix -sweep -user $login -password $senha $dir/BACKUP/temporario.gdb

5º Realizar o backup da base que recebeu manutenção (não é a que está online)
# /usr/lib64/firebird/bin-superserver/gbak -b -t -g -co -user $login -password $senha $dir/BACKUP/temporario.gdb $backup -y $dir/BACKUP/LOG/bar$data3.log -v

6º Compactar a base backupeada
# gzip -v $backup

7º Remover as bases temporárias, os backups antigos, etc.
#Removendo arquivos antigos
echo "Removendo backups com mais de 30 dias"
find /home/empresa/BACKUP/BAR/ -ctime +30 -exec rm -rf {} \;
echo "Backups antigos removidos com sucesso!"
echo "Backup realizado com sucesso!"
echo "Removendo Logs com mais de 30 dias"
find /home/empresa/BACKUP/LOG/ -ctime +30 -exec rm -rf {} \;
echo "Logs antigos removidos com sucesso!"
echo "Removendo cópia da base de dados"
rm -f /home/empresa/BACKUP/teporário.gdb
Echo "backup realizado com sucesso"
***************************************************************

Desculpe-me por tantas perguntas.
Se este banco parar, eu "to no sal".
O Backup tem que rodar sem nenhum erro.
Se for o caso de restaurar, a base já deve estar em estado de "PRONTA" para restauração, ou seja, não haverá tempo para executar uma manutenção do backup antes da restauração.

[]´s
Raphael Monteiro