Resposta rápida

Backup Firebird correto usa o gbak — utilitário oficial que lê o banco de forma transacional e gera um .fbk íntegro, mesmo com o banco em uso. Copiar o arquivo .fdb diretamente com o serviço no ar cria uma cópia inconsistente que pode não restaurar na hora que você mais precisar.

Mas Maurício, o sistema já gera backup todo dia — ele copia o .fdb automaticamente, então tá protegido, né?

Essa é a frase que mais me preocupa quando um técnico me conta como está a proteção do cliente dele. Porque copiar o .fdb com o Firebird rodando é uma das armadilhas mais silenciosas que existe em pequenas e médias empresas brasileiras.

Você olha a pasta, vê o arquivo lá, o relatório marca “OK”. Mas na hora do restore — HD queimado, servidor comprometido, troca de máquina — o arquivo simplesmente não abre. Ou pior: abre com erro de integridade, com registros faltando, com as últimas horas de trabalho perdidas.

Backup Firebird (ou becape do Firebird) feito do jeito errado cria a ilusão de proteção. E ilusão de proteção é mais perigosa do que não ter backup nenhum — porque você para de procurar o problema até o dia que ele te encontra.

Neste post vou te explicar por que isso acontece e como fazer do jeito certo, com o utilitário oficial. Se você ainda está construindo o conceito de por que backup de banco de dados é diferente de backup de arquivos comuns, recomendo começar pelo backup de banco de dados antes de continuar aqui.

Por que copiar o .fdb com o banco no ar é roleta-russa?

O Firebird armazena tudo — estrutura e dados — em um único arquivo .fdb (ou .gdb em versões antigas). Parece simples. Mas por baixo desse arquivo único existe uma estrutura de páginas em memória, transações em aberto, e um processo contínuo de escrita em disco.

Quando você copia o .fdb com o serviço no ar, você está congelando esse arquivo no meio de uma operação. O resultado é uma cópia que reflete um estado parcial do banco — páginas que foram escritas até a metade, transações que não fecharam, índices inconsistentes com os dados.

Tecnicamente isso se chama cópia de arquivo inconsistente. Na prática, se chama: o banco não abre no restore.

Vou ser honesto aqui: não sei o exato comportamento de cada versão do Firebird em cada cenário de cópia — a lógica de flush de páginas pode variar. O que eu sei, de prática no campo, é que copiar o .fdb cru é roleta-russa. Às vezes funciona. Às vezes não. E você só vai descobrir qual foi quando precisar recuperar.

O .fbk que o gbak gera é diferente do .fdb?

Completamente diferente. O gbak é o utilitário oficial do Firebird para backup e restore. Ele não copia o arquivo físico — ele lê o banco de forma lógica e transacional: exporta estrutura e dados, página por página, garantindo consistência mesmo com o banco em uso.

O arquivo gerado é o .fbk. Esse é o arquivo que vale. Ele pode ser restaurado em qualquer servidor com Firebird na mesma versão ou mais recente, e o gbak valida o banco durante o processo — se tiver corrupção no .fdb original, o gbak acusa durante o backup, antes de você precisar descobrir isso no pior momento.

Existe também o nbackup, que faz cópia física incremental. Menciono pra você saber que existe — mas fique com o gbak. O nbackup, se o processo for interrompido por qualquer motivo, deixa o banco em modo delta acumulando mudanças indefinidamente, sem concluir. Já vi banco parar por isso.

Método Consistência Banco pode ficar no ar? Restaura? Recomendado?
Copiar .fdb cru Não garantida (páginas em escrita) Sim (mas o risco é esse) Talvez — depende da sorte Não
gbak (.fbk) Garantida (leitura transacional) Sim Sim, sempre Sim

Como fazer o backup Firebird com gbak (passo a passo)?

O fluxo que usamos — e recomendamos — é o seguinte: fazer um shutdown controlado e brevíssimo via gfix, copiar o .fdb pra uma pasta temporária, reativar o banco imediatamente, e rodar o gbak sobre a cópia. O banco fica indisponível por segundos; o gbak trabalha na cópia enquanto o sistema já está de volta para os usuários.

Aqui estão os comandos:

:: Coloca o banco em shutdown controlado (aguarda ate 100s pelas transacoes ativas)
gfix -sh -tr 100 -fo 100 -user SYSDBA -pas masterkey localhost:C:\Dados\Sistema.fdb

:: Copia o .fdb para pasta temporaria
copy C:\Dados\Sistema.fdb C:\WSPEED\BACKUP\Validar\Sistema.fdb

:: Reativa o banco imediatamente (usuarios ja podem entrar)
gfix -online normal -user SYSDBA -pas masterkey localhost:C:\Dados\Sistema.fdb

:: Roda o gbak sobre a copia (banco ja esta online de novo)
gbak -backup -v -ig -y C:\WSPEED\BACKUP\Logs\backup.txt ^
  localhost:C:\WSPEED\BACKUP\Validar\Sistema.fdb ^
  C:\WSPEED\BACKUP\Sistema-backup.fbk

Os parâmetros importantes: -v ativa o verbose (você vê o que está acontecendo no log), -ig ignora erros não críticos de integridade durante o dump, -y redireciona a saída para um arquivo de log que você pode checar depois.

Atenção no caminho do gbak. Em versões 2.5, normalmente fica em C:\Program Files (x86)\Firebird\Firebird_2_5\bin\gbak.exe. Em versões 3.x e 4.x o caminho muda. Muita gente roda o Firebird embutido dentro do sistema ERP e nem sabe qual versão está instalada — confirme qual versão do Firebird está instalada (2.5, 3.x ou 4.x) antes de montar o script, porque o caminho do gbak muda conforme a versão.

Como restaurar um .fbk no Firebird?

Mas Maurício, e se eu precisar restaurar — como funciona na prática?

O restore com gbak é direto. O parâmetro -c cria um banco novo a partir do .fbk; o -r substitui se o arquivo de destino já existir:

set GBAK="C:\Program Files (x86)\Firebird\Firebird_2_5\bin\gbak.exe"
set ISC_USER=SYSDBA
set ISC_PASSWORD=masterkey

%GBAK% -c -r -user %ISC_USER% -pas %ISC_PASSWORD% -p 8192 -v ^
  C:\WSPEED\BACKUP\Sistema-backup.fbk ^
  localhost:C:\WSPEED\RESTORE\SistemaRestaurado.fdb

O -p 8192 define o page size em 8 KB — padrão moderno para Firebird 2.5+. Se o banco original foi criado com 4 KB (versões antigas), use o mesmo valor que o original, senão o restore pode falhar.

Um ponto que pouca gente faz mas que é obrigatório: teste o restore periodicamente, em ambiente separado, sem aviso prévio. Rode o restore num servidor de teste, abra o banco, confirme que as tabelas estão lá, que os registros mais recentes aparecem. Fazer isso uma vez por mês — ou pelo menos uma vez por trimestre — é o que separa backup de verdade de falsa segurança.

Se você quer entender por que “fazer backup” e “ter backup” são coisas diferentes, vale ler o post sobre o que é backup.

O .fbk ficou no servidor — e agora?

Você já imaginou fazer backup Firebird todos os dias durante meses e descobrir que o .fbk está no mesmo servidor que o sistema?

Ransomware criptografa tudo que está acessível no servidor — inclusive a pasta de backup local. HD queima e leva o .fdb e o .fbk juntos. Servidor pega fogo ou fica debaixo d’água (como aconteceu com 9 clientes nossos na enchente do Rio Grande do Sul em maio de 2024 — recolocamos todos de pé em dias, porque o dado deles estava na nuvem, longe do problema).

O .fbk na pasta local é um arquivo temporário esperando o pior acontecer. O backup de verdade só existe quando sai do servidor.

O fluxo completo que recomendamos é este:

  1. Script com gfix + gbak gera o .fbk na pasta local.
  2. O arquivo vai pra nuvem criptografada imediatamente (off-site).
  3. A nuvem guarda versões por 7, 15 ou 30 dias (rotativo).
  4. Restore testado mensalmente em ambiente separado.

Aqui na WSpeed, o nosso backup em nuvem para empresas monitora a pasta onde o gbak deposita o .fbk e envia cada arquivo novo pro Backblaze B2 — nosso armazenamento primário, especializado em backup e mais econômico — com criptografia AES-256 e retenção configurável. Se precisar, o arquivo também vai pro AWS S3. Sem ação manual, sem depender de alguém lembrar de copiar.

Se você cuida da TI de vários clientes e muitos deles rodam sistemas em Firebird, dá uma olhada em como trabalhamos com soluções para empresas de TI — o modelo de parceria para MSP faz sentido exatamente pra esse tipo de cenário.

Por onde começar se você está montando isso agora?

Não precisa virar especialista em Firebird para montar uma rotina decente. O resumo prático é este:

  1. Identifique qual versão do Firebird está instalada (2.5, 3.x ou 4.x) e onde fica o gbak — o caminho muda conforme a versão.
  2. Monte o script com gfix + copy + gfix online + gbak. Use os comandos deste post como ponto de partida.
  3. Agende o script para rodar fora do horario comercial (00h, 01h) via Agendador de Tarefas do Windows.
  4. Monitore o log gerado pelo -y do gbak — qualquer erro aparece ali.
  5. Configure o envio do .fbk pra nuvem assim que o arquivo for gerado.
  6. Teste o restore. Sem isso, os passos anteriores são só esperança.

Para os outros bancos de dados que você encontra nas empresas — SQL Server, MySQL, PostgreSQL, Oracle — o post de backup de banco de dados cobre os comandos nativos de cada um com o mesmo nível de detalhe.

Me conta nos comentários: qual é a versão do Firebird que mais aparece nos seus clientes — e já pegou algum backup de .fdb que simplesmente não restaurou na hora H? Aposto que tem história boa (ou dolorosa) por aí.

Abraço e até o próximo artigo ou vídeo.

Perguntas frequentes

Posso copiar o .fdb com o banco aberto?

Não é recomendado. O Firebird mantém páginas sendo escritas em disco durante o uso, e copiar o .fdb com o serviço no ar pode resultar em um arquivo inconsistente — você acha que tem backup, mas tem um .fdb que não restaura. O caminho certo é usar o gbak ou fazer uma janela de parada controlada via gfix antes de copiar.

O que é gbak?

gbak é o utilitário oficial de backup e restore do Firebird. Ele lê o banco de forma lógica e transacional — exportando estrutura e dados com consistência garantida — e gera um arquivo .fbk que pode ser restaurado em qualquer servidor com Firebird na mesma versão ou mais recente.

Como restaurar um .fbk?

Use o gbak com o parâmetro -c (create) para criar um banco novo a partir do .fbk, ou -r (replace) para substituir um existente. Exemplo: gbak -c -r -user SYSDBA -pas masterkey backup.fbk localhost:C:\Dados\SistemaRestaurado.fdb. Confirme a versão do Firebird no servidor de destino antes de restaurar.

Preciso parar o serviço para fazer backup Firebird?

Não necessariamente. O gbak consegue gerar um backup consistente com o banco em uso. A alternativa mais segura — especialmente em sistemas com muita escrita simultânea — é fazer um shutdown controlado e breve via gfix (-sh -tr), copiar o .fdb para uma pasta temporária, reativar o banco imediatamente e rodar o gbak sobre a cópia. O banco fica offline por segundos.

Como mandar o backup Firebird pra nuvem?

Depois que o gbak gera o .fbk na pasta local, você precisa que esse arquivo saia do servidor — porque ransomware, HD queimado ou servidor destruído levam o .fbk junto. A WSpeed monitora a pasta de destino e envia cada arquivo novo para o Backblaze B2 (armazenamento primário) com criptografia AES-256 e versionamento, sem ação manual.