Using gbak with the Firebird Service Manager - Firebird

The –se[rvice_mgr] switch invokes the Service Manager on a (usually) remote server. It can save a significant amount of time and network traffic when you want the backup or the restored file to be created on the host on which the database resides.

On a Windows server, with a local connection, using the Service Manager offers no advantage.

On a POSIX server, it saves time and traffic—even on a localhost connection.

When you run gbak with the –service_mgr switch, it operates differently from the way it does otherwise. It causes gbak to invoke the backup and restore functions of Firebird’s Service Manager on the server where the database resides.

You can back up to multiple files and restore from multiple files using Service Manager.

The –se switch takes an argument that consists of the host name of the server concatenated to the constant string service_mgr by a special symbol. The syntax of this argument varies according to the network protocol you are using:

  • TCP/IP: hostname:service_mgr
  • Named Pipes

Restoring on POSIX

The user that was current on the server when the Service Manager was invoked to perform the backup—either root, firebird, or interbase—is the owner the backup file at the
filesystem level, causing it to be readable to only that user.

When you need to restore a database on a POSIX server that has been backed up using the Service Manager, you must either use the Service Manager for the restore or be logged into the system as that file owner.

When the –service option is not used, the filesystem ownership of the backup file is attributed to the login of the person who ran gbak.

These constraints don’t apply on Windows platforms.


In this example, we back up a database residing on the remote server’s D drive to a backup file on the F drive of the same remote machine. We pass the verbose output of the operation to a log file in another directory. As usual, the example is a single string:

gbak -b -se hotchicken:service_mgr hotchicken:d:\data\stocks.fdb f:\backups\stocks.20040715.fbk -v -y f:\backups\logs\stocks.20040715.log


The next example restores a multi-volume database from the /january directory of the hotchicken server to the /currentdb directory. It uses the –r[eplace_database] switch and will overwrite the database magic.fdb if it is found in /currentdb. The first two files of the restored database are 500 pages long and the last file grows as needed.

gbak -r -user frodo -pas pipeweed -se hotchicken:service_mgr /january/magic1.fbk /january/magic2.fbk /january/magicLast.fbk /currentdb/magic.fdb 500 /currentdb/magic.fd2 500 /currentdb/magic.fd3

The next example executes on server hotchicken and restores a backup that is on hotchicken to another server called icarus:

gbak -c -user frodo -pas pipeweed -se hotchicken:service_mgr /january/magic.fbk icarus:/currentdb/magic.fdb

All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd Protection Status

Firebird Topics