Firebird SQL’s backup/restore uses magic words for stdin and stdout – Check the gbak manual update

After An interesting read.

Norman Dunbar updated the gbak manual with the following:

A section on the use of stdin and stdout “file names” and how to clone
a database – on the same server – using a pipe and these “file names” to
avoid the use of a temporary intermediate dump file.

A section on carrying out remote backups and restores using the above
as well as an ssh session. This allows a remote database to be cloned to
a local server, a local database to be cloned to a remote server and a
remote database to be cloned to (another) remote server.

Further updates to document the use of the stdin and stdout file names in backups and restores. A section has been added to Gbak Caveats giving more in depth detail about these two special file names.

Change made to make Faster restores with gbak

There is a simple change which makes restores much faster, tested with Linux 2.5 embedded restore
Two databases, with two different tables filled with 2,000,000 records:
create table t1 (n1 integer);
create table t10 (n1 integer, n2 integer, n3 integer, …, n10 integer);

Restore timings:
T1: 14.5s
T10: 20.5s

Improved gbak timings:
T1: 9.7s
T10: 14.7s

The good news is there is still room to improve the restore speeds , here is Adriano’s tweet:

I do have a slight different method, to insert 100K records in less than 1s over the same localhost method.

Also confirmed by the ending of the article:

PS: There is other restore improvement capable of take down time from
around 8.5s to 0.5s over TCP, but it still requires some analisys.

How to increase Firebird backup and restore speed (up to 30%)

It seems that many Firebird developers and administrators are not aware about  command line switch -se[rvice] for gbak.exe

-SE[RVICE] <servicename>

This switch causes gbak to backup a remote database via the service manager. This causes the backup file to be created on the remote server, so the path format and filename must be valid on the remote server. The servicename is currently always the text service_mgr.

here is the rest of the article in Eglish

also there is an Italian mention in blogosphere