Before you consider using other tools to take a backup of your Firebird database, make sure that you know what the tools do and how a running database will be affected by them. For example, if you use Winzip to create a compressed copy of a database and you do it when users are accessing the system, the chances of a successful restore of that database are slim. You must either always use the gbak or nbackup tools which know how the database works, or, use gfix to shut the database down completely before you even attempt to backup the database file(s).

gbak creates a consistent backup of the database by starting a transaction that spans the backup period. When the backup is complete, the transaction is ended and this means that the backup process can be run while users are working in the database. However, any transactions started after the backup process begins will not have any of the changed data written to the backup file. The backup will represent a copy of the entire database at the moment the backup began.

The dump file created by a default gbak backup is cross platform (transportable) so a backup taken on a Windows server can be used to recreate the same database on a Linux server, or on any other platform supported by Firebird. This is not true of the copies of your database taken (while the database was closed!) with tools such as Winzip etc. Those copies should only ever be used to restore a database on the same platform as the one copied.

Important: Always backup the database with the version of gbak supplied with the running database server.

And one final thought on backups, regardless of the fact that the backup finished with no errors, exited with an error code of zero and all appears to be well, how do you actually know that the backup file created is usable? The short answer is, you don't. Whenever you have a valuable database - and they all should be - you are strongly advised to take your backup files and use them to create a test restore of a database either on the same server or even better, on a different one. Only by doing this can you be certain of a successful backup.

The following example shows a backup being taken on a server named linux and used to create a clone of the database on another Linux server named tux to make sure that all was well. First of all, the backup on linux:

linux> gbak -backup -verify -y backup.log employee employee.fbk
linux> gzip -9 employee.fbk

Note: Note that the above gbak command can be written as follows, leaving out the -b[ackup] switch as gbak defaults to running a backup when no other suitable switches are specified:

linux> gbak -verify -y backup.log employee employee.fbk

Then, on the tux server:

tux> scp norman@linux:employee.fbk.gz ./

Using keyboard-interactive authentication.
Password:
employee.fbk.gz           |         19 kB |   19.3 kB/s |  ETA: 00:00:00 | 100%

tux> gunzip employee.fbk.gz
tux> gbak -replace -verify -y restore.log employee.fbk employee.restore.test

At this point, the restore has worked and has overwritten the previous database known as employee.restore.test.

The actual location of the database for the database employee.restore.test is defined in the aliases.conf file in /opt/firebird on the server. In this test, it resolves to /opt/firebird/databases/employee.restore.fdb.

For further proof of reliability, the application may be tested against this clone of the live database to ensure all is well.

There are a couple of tricks you can use to speed up the backup. The first is to prevent the garbage collection from being carried out while the backup is running. Garbage collection clears out old record versions that are no longer required and this is usually covered by a sweep - manual or automatic - or by a full table scan of any affected table. As gbak accesses all the rows in the tables being backed up, it too will trigger the garbage collection and, if there have been a large number of updates, can slow down the backup. To prevent garbage collection during the backup, use the -g[arbage_collect] option.

tux> gbak -backup -garbage_collect employee /backups/employee.fbk

The second option is to backup the database using the -se[rvice] option. Although this is used to perform remote backups, it can be used locally as well. Using this option can help speed up your backups. It simply avoids the data being copied over the TCP network which can slow down the actions of the backup.

tux> gbak -backup -service tux:service_mgr employee /backups/employee.fbk

The example above backs up the employee database, on the tux server, “remotely” using the service manager. The tux server is, of course, where the command is running, so it isn't really running remotely at all.

You can, of course, combine the -g[arbage_collect] and -se[rvice] options.