FirebirdSQL logo

Speeding up the Restore

The restoration of a database, from a backup, can be made to execute quicker if the -⁠se[rvice] option is used.Although this is used to perform remote restores, it can be used locally as well.It simply avoids the data being copied over the TCP network which can slow down the actions of the restore.

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

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.

Security Of Backups

As you have seen above, anyone, with a valid username and password, can restore a gbak database backup file provided that they are not overwriting an existing database (in Firebird 3.0 and higher, they will also need the CREATE DATABASE DDL privilege).This means that your precious data can be stolen and used by nefarious characters on their own servers, to create a copy of your database and see what your sales figures, for example, are like.

To try and prevent this from happening, you are advised to take precautions.You should also prevent backups from being accidentally overwritten before they have expired.Some precautions you can take are:

  • Always set the backup file to be read-only after the backup is complete.This helps prevent the file from being overwritten.

  • Alternatively, incorporate the date (and time) in your backup filenames.

  • Keep backups in a safe location on the server.Storing backups in a location with restricted access helps reduce the chances of your backup files 'escaping' into the wild.

  • Keep tape copies of your backups very secure.A locked safe or off-site location with good security is advisable.The off-site location will also be of use after a total disaster as the backups are stored in a separate location to the server they are required on.

  • Backup to a partition or disk that has encryption enabled.

  • Encrypt the backup file — supported by Firebird 4.0 and higher.

  • Make sure that only authorised staff have access to areas where backups are kept.

  • Always test your backups by cloning a database from a recent backup.

In Firebird 2.1, there is an additional security feature built into gbak and all the other command-line utilities.This new feature automatically hides the password if it is supplied on the command line using the -⁠password switch.Gbak replaces the password with spaces — one for each character in the password.This prevents other users on the system, who could run the ps command and view your command line and parameters, from viewing any supplied password.In this manner, unauthorised users are unable to obtain the supplied password.

tux> gbak -b -user SYSDBA -passw secret employee /backups/employee.fbk
tux> ps efx| grep -i gba[k]
20724 ... gbak -backup -user SYSDBA -passw           employee employee.fbk
... (lots more data here)

You can see from the above that the password doesn’t show up under Firebird 2.1 as each character is replaced by a single space.This does mean that it is possible for someone to work out how long the password could be and that might be enough of a clue to a dedicated cracker.Knowing the length of the required password does make things a little easier, so for best results use a random number of spaces between -⁠passw and the actual password.The more difficult you make things for the bad people on your network, the better.

Backup & Restore Recipes

The following recipes show examples of backup and restore tasks using gbak.These are probably the commonest cases that you will encounter as a DBA.All the examples use the employee database supplied with Firebird and the actual location is correctly configured in aliases.conf.

Each of the following recipes is run with the assumption that the environment variables ISC_USER and ISC_PASSWORD have been given suitable values.If you don’t have these set, you will need to supply the appropriate options [gbak-cmdline-user] and [gbak-cmdline-password], or [gbak-cmdline-trusted] — Windows-only, on the commandline.

Backup & Restore Prerequisites

If you replace an open and running database, there is a good chance that you will corrupt it.For best results and minimal chance of corrupting a database, you should close it before replacing it.To close a database, use gfix as follows:

tux> gfix -shut -tran 60 employee

The example above prevents any new transaction from being started which prevents new queries being executed or new sessions connecting to the database.It will wait for up to 60 seconds for everyone to logout and for all current transactions to complete before shutting down the database.If any long-running transactions have not completed by the end of 60 seconds, the shutdown will timeout and the database will remain open.

Note

After the restore of the database has completed, the database will automatically be opened again for use.