Firebird's 5.0.4 gbak crash when using parallel workers

[Fabiano SCI]

Hi folks!

I'm using gbak from Firebird 5.0.4.1812 (x64 on Windows) to backup a database with this command:

'C:\Program Files\Firebird\Firebird_5_0\gbak.exe -b "C:\SCI\banco\vsci.SDB" "C:\SCI\banco\vsci_SDB_QUI_1021.sci" -user SYSDBA -password masterkey -zip -verbint 100000 -G -D -PAR 8 -se 127.0.0.1:service_mgr'

The backup starts and runs for a while until it reaches the table TATUMUNICIPAL then it stops with ResultCode = 1. On the firebird.log file at that timestamp there is this information:

INET/inet_error: read errno = 10053, server host = 127.0.0.1, address = 127.0.0.1/3050

Which suggests a crash in the engine IMHO.

When I redo the backup withou the -PAR 8 switch backup runs fine. 

Also, when restoring this backup with -PAR 8 the firebird instance hangs. My only solution is supress -PAR.

This symtom algo occurs before a full backup/restore cycle. It occurs in SuperServer and Classic also.

A copy of this database can be found:

https://we.tl/t-cXRF8bJP3bxWWzML

and here:

http://fkureck.duckdns.org:18080/p/ape-ape-panda

[Fabiano SCI]

"This symtom algo occurs before a full backup/restore cycle" is actually   "This symtom algo occurs after a full backup/restore cycle"

[Vlad Khorsun]

Hi folks!

I'm using gbak from Firebird 5.0.4.1812 (x64 on Windows) to backup a database with this command:

'C:\Program Files\Firebird\Firebird_5_0\gbak.exe -b "C:\SCI\banco\vsci.SDB" "C:\SCI\banco\vsci_SDB_QUI_1021.sci" -user SYSDBA -password masterkey -zip -verbint 100000 -G -D -PAR 8 -se 127.0.0.1:service_mgr'

The backup starts and runs for a while until it reaches the table TATUMUNICIPAL then it stops with ResultCode = 1.

Does you read gbak output ? It prints exact reason of failure:

gbak: ERROR:database VSCI.SDB shutdown
gbak:Exiting before completion due to errors

 

On the firebird.log file at that timestamp there is this information:

INET/inet_error: read errno = 10053, server host = 127.0.0.1, address = 127.0.0.1/3050

Which suggests a crash in the engine IMHO.

No, it is not.

 

When I redo the backup withou the -PAR 8 switch backup runs fine.  

Also, when restoring this backup with -PAR 8 the firebird instance hangs. My only solution is supress -PAR.

This symtom algo occurs before a full backup/restore cycle. It occurs in SuperServer and Classic also.

A copy of this database can be found:

https://we.tl/t-cXRF8bJP3bxWWzML

The database  is in single-user shutdown mode, run gfix -h and see yourself.

It prevents anyone, including gbak, to run more than one attachment.

Please, be more careful next time ;)

Regards,

Vlad

[Fabiano SCI]

So, really that what you saidm thanks!. For various reasons the gbak output was not present to me at that time.

But there is a reason for my database to be in single-user shutdown mode. Since a long time agora Firebird's documentation claim that connecting on a database while restoring a backup can lead to a corruption. So in my case I always put my database in single-user mode to avoid it.

With Firebird 5.0.4 I must care about corruption during restore if someone connects to my database?

[Dimitry Sibiryakov]

Fabiano SCI wrote 21.08.2026 14:07:
> With Firebird 5.0.4 I must care about corruption during restore if someone
> connects to my database?

Database is already in single-user mode during restore. There is no need to
do it explicitly.

--
WBR, SD.

[Vlad Khorsun]

So, really that what you saidm thanks!. For various reasons the gbak output was not present to me at that time.

But there is a reason for my database to be in single-user shutdown mode. Since a long time agora Firebird's documentation claim that connecting on a database while restoring a backup can lead to a corruption. So in my case I always put my database in single-user mode to avoid it.

One more myth. 

I can imagine than one might break **gbak restore ** operations, yes (with some bad luck), but it is not about database "corruption".

 

With Firebird 5.0.4 I must care about corruption during restore if someone connects to my database?

If you afraid of such "corruption" - restore database into different name and rename later or/and change

SYSDBA password and hide it from "so evil" users.

Regards,

Vlad

[Vlad Khorsun]

Fabiano SCI wrote 21.08.2026 14:07:
> With Firebird 5.0.4 I must care about corruption during restore if someone
> connects to my database?

Database is already in single-user mode during restore.

Not in case of parallel restore.

 

There is no need to do it explicitly.

Sure.

Regards,

Vlad