FirebirdSQL logo

A Simple Backup & Restore

This example takes a backup, then immediately overwrites the original database using the new backup.This is not normally a good idea as the first action of the -⁠recreate overwrite is to wipe out the database.

tux> # Backup the database.
tux> gbak -backup employee /backups/employee.fbk

tux> # Restore the database.
tux> gfix -shut -tran 60 employee
tux> gbak -recreate overwrite /backups/employee.fbk employee

Metadata Only

It is possible to use gbak to recreate an empty database containing only the various domains, tables, indices and so on, of the original database but none of the data.This can be useful when you have finished testing your application in a test environment and wish to migrate the system to a production environment, for example, but starting afresh with none of your test data.

tux> #Backup only the database metadata.
tux> gfix -shut -tran 60 employee
tux> gbak -backup -meta_data employee employee.meta.fbk

When the above backup file is restored on the production server, only the metadata will be present.

There is another way to create a database with no data and only the metadata.Simply restore from an existing backup which contains the data and supply the [gbak-cmdline-meta-data] switch to the restore command line.The database will be restored but none of the original data will be present.

tux> #Restore only the database metadata.
tux> gbak -create employee.fbk mytest.fdb -meta_data

The [gbak-cmdline-meta-data] switch can be used on either a backup or a restore to facilitate the creation of a clone database (or overwrite an existing one) with no actual data.

Splitting The Backup

The gsplit filter application, documented in its own manual, doesn’t actually work anymore.This filter was supplied with old versions of InterBase and Firebird to allow large database backups to be split over a number of files so that file system limits could be met.Such limits could be the size of a CD, the 2GB limit on individual file sizes on a DVD, where some Unix file systems have a 2 GB limit and so on.

Gbak allows the backup files to be split into various sizes (with a minimum of 2048 bytes) and will only create files it needs.

tux> # Backup the database to multiple files.
tux> gbak -backup employee /backups/emp.a.fbk 600m /backups/emp.b.fbk 600m

The sizes after each filename indicate how large that particular file is allowed to be.The default size is bytes, but you can specify a suffix of k, m or g to use units of kilo, mega or gigabytes.

If the backup completes before writing to some files, then those files are not created.A backup file is only ever created when it must be.

The size of the final backup file will be quietly ignored if the database has grown too large to allow a truncated backup to complete.If, in the example above, the backup needs a total of 1500M, then the last file would be written to a final size of 900m rather than the 600m specified.

To restore such a multi-file backup requires that you specify all filenames in the backup and in the correct order.The following example shows the employee database above being restored from the two files backed up above:

tux> # Restore the database from multiple files.
tux> gfix -shut -tran 60 employee
tux> gbak -r o /backups/employee.a.fbk /backups/employee.b.fbk employee

Changing The ODS

Normally the ODS used is the one in force by the version of Firebird used to restore the database.So, the examples above will actually change the ODS when the database is restored.The backup should be taken using the gbak utility supplied by the old ODS version of Firebird.The restore should be carried out using gbak from the newer version of Firebird.

tux> setenv_firebird 2.0
Firebird environment set for version 2.0.

tux> # Check current ODS version (as root user!)
tux> gstat -h employee|grep ODS
        ODS version             11.0

tux> # Backup the (old) database.
tux> gbak -backup employee /backups/employee.2_0.fbk

tux> setenv_firebird 2.1
Firebird environment set for version 2.1.

tux> # Recreate the database and upgrade the ODS.
tux> gfix -shut -tran 60 employee
tux> gbak -r o /backups/employee.2_0.fbk employee

tux> # Check new ODS version (as root user!)
tux> gstat -h employee|grep ODS
        ODS version             11.1

After the above, the old 2.0 Firebird database will have been recreated — wiping out the old database — as a Firebird 2.1 database with the corresponding upgrade to the ODS from 11.0 to 11.1.

The script setenv_firebird is not supplied with Firebird and simply sets PATH, etc., to use the correct version of Firebird as per the supplied parameter.