FirebirdSQL logo

-⁠I[NACTIVE]

Do not activate indexes after restore.

This switch can be used to restore a database when a previous restore attempt failed due to index errors.All indexes in the restored database will be inactive, and as a consequence all primary key, unique key and foreign key constraints as well.

-⁠K[ILL]

Kill (do not recreate) shadow database.

This switch restores the database but doesn’t recreate any shadow files that existed previously.

-⁠MO[DE]

Restore database in read-only or read/write mode.

Syntax
-MO[DE] { READ_ONLY | READ_WRITE }

This switch allows the database being restored to be set to the given access mode when opened.By default, the mode is taken from the database that was backed up.

Caution

This option should not be confused with the replica mode configured through [gbak-cmdline-replica].For example, a database created with -⁠REPLICA READ_ONLY is still writable by the replicator connection, while a database created with -⁠MODE READ_ONLY is not writable at all.

Backup Mode

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, enable the database backup mode with ALTER DATABASE BEGIN BACKUP (and end it with ALTER DATABASE END BACKUP), 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 their changed data written to the backup file.The backup will represent a copy of the entire database at the moment the backup began.

The backup 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 or in backup-mode!) 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 -r o -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.