1. Qual é o sintoma?
Um backup executado com o gbak usando a opção de paralelismo (-PAR n) inicia normalmente, processa várias tabelas e,
ao chegar em determinada tabela, é interrompido retornando ResultCode = 1. No firebird.log, no mesmo horário,
aparece uma entrada semelhante a:
INET/inet_error: read errno = 10053, server host = 127.0.0.1, address = 127.0.0.1/3050
Sem a opção -PAR, o mesmo backup conclui sem erros. E, ao tentar restaurar também com -PAR, o processo parece travar.
2. Isso é um crash (falha) do engine do Firebird?
Não. A mensagem INET/inet_error ... errno = 10053 apenas informa que a conexão TCP foi encerrada abruptamente pelo outro lado.
Ela é uma consequência do erro, não a causa. O servidor não caiu.
3. Onde está a mensagem real do erro?
Na saída do próprio gbak (stdout/stderr), que costuma ser ignorada quando o comando é disparado por um agendador ou por uma aplicação. Ela traz o
motivo exato:
gbak: ERROR:database NOMEDOBANCO.FDB shutdown
gbak: Exiting before completion due to errors
Sempre capture e leia essa saída antes de investigar o log do servidor.
4. Qual é a causa raiz?
O banco de dados está em shutdown no modo single-user (modo de manutenção mono-usuário). Nesse estado, o Firebird permite apenas uma conexão simultânea ao banco.
O backup paralelo funciona abrindo vários workers, e cada worker precisa de sua própria conexão com o banco. A primeira conexão é aceita; as demais são recusadas com o erro de banco em shutdown, e o gbak aborta a operação.
5. Por que sem -PAR o backup funciona?
Porque o gbak, em modo serial, utiliza uma única conexão — exatamente o limite que o modo single-user permite. Ou seja, remover o -PAR não
corrige nada: apenas mascara o estado incorreto do banco.
6. Como confirmar o estado do banco?
Consulte o cabeçalho do banco e observe a linha de atributos:
gstat -h C:\caminho\banco.fdb -user SYSDBA -password ******
Se aparecer algo como Attributes: single-user maintenance (ou multi-user maintenance / full shutdown), o banco não está online. Estando conectado, também é possível verificar via SQL:
SELECT MON$SHUTDOWN_MODE FROM MON$DATABASE;
O valor 0 indica online; qualquer valor diferente indica algum nível de shutdown.
6.1. E se o banco estiver em multi-user maintenance?
Nesse modo o Firebird aceita várias conexões simultâneas,
desde que sejam de SYSDBA, do owner do banco ou de usuários com a role
RDB$ADMIN. Como o gbak já exige um desses perfis
para operar, um backup paralelo tende a funcionar mesmo com o banco nesse
estado.
A diferença entre os modos está no que cada um restringe:
multi — várias conexões, apenas para perfis administrativos.single — uma única conexão, apenas para perfis administrativos.full — nenhuma conexão.
É justamente por isso que o problema descrito neste FAQ se manifesta apenas
com -PAR: o modo single não barra o backup por
falta de permissão, e sim por esgotar o limite de uma conexão assim que o
segundo worker tenta se conectar. Ainda assim, nenhum modo de
manutenção é estado adequado para um banco em produção — devolva-o
para online com gfix -online.
7. Como resolver?
Devolva o banco ao estado online normal:
gfix -online C:\caminho\banco.fdb -user SYSDBA -password ******
Depois disso, repita o backup com -PAR normalmente. Confirme com o gstat -h que o atributo de manutenção desapareceu antes de reexecutar.
8. Como o banco foi parar nesse estado?
Quase sempre por uma rotina de manutenção que colocou o banco em shutdown (por exemplo gfix -shut single -at 0, usado antes de um
-mend, de uma cópia física ou de uma atualização de metadados) e não o devolveu para online — seja por falha no meio do script, seja por interrupção manual. O estado é persistente: sobrevive ao restart do serviço.
9. Checklist rápido
- Leia e registre a saída do
gbak; não diagnostique apenas pelo firebird.log.
- Verifique o estado do banco com
gstat -h.
- Se houver atributo de manutenção, execute
gfix -online.
- Nos scripts de manutenção, sempre coloque o
gfix -online em bloco de finalização, inclusive em caso de erro.
- Não use a remoção do
-PAR como solução definitiva — ela apenas esconde o problema.
Resumo: o erro de rede no log e a falha do backup paralelo são sintomas; a causa é o banco estar em shutdown mono-usuário, o que impede mais de uma conexão simultânea.
