meta data for this page
Backup
Firebird database backups should be performed for the following reasons:
- The database file (.fdb file) should not be backed up directly as a file, as it is not compatible with other platforms and Firebird/InterBase® versions.
- Moreover the .fdb file is in an instable condition if one or more users are connected to the database (open edit access etc.). This is also an argument against backing up the database file at file level.
- No empty page areas or indices need to be stored in the backup. The backup file is therefore (usually much) smaller.
- Databases can also be repaired or reduced in size by performing a backup and restore.
- If a database needs to be ported to another platform (e.g. from a Windows server to a Linux server), it is not the database file that is ported but the backup. This is then imported to the destination server by performing a restore of the backup file.
A backup generates a backup file. This has its own file format and contains a consistent data view, because the backup extract the data as an independent transaction.
A backup can be carried out during runtime. During this time database performance may degrade, particularly if the backup runs for some time.
The usual suffix for backup files is: .fbk
Backup in productive environments
Productive systems should be backed up regularly. The .fdb backup file can be backed up using conventional file backup methods.
If the server runs through the night, the backup can be started by a scheduler (Windows: AT service, Linux: cron).
Windows
The AT command can be used to issue tasks to a Windows NT server (NT4, 2000, XP, 2003), which should be performed at a certain specified time.
Example: A database should be backed up nightly at 4 am. Enter the following command in the Windows prompt:
at 04:00 /every:mo,di,mi,do,fr,sa,so /interactive -> c:\Programme\Firebird\bin\gbak -t -user SYSDBA -password masterkey -> harry:c:\DB\pmm.fdb k:\Backups\pmm.fbk
Tip: Do not run such tasks nightly between 02:00 and 03:00. When clocks are put forward to summer time in the Spring this hour does not exist at all, when changing back in the Fall, this hour occurs twice.
See also:
gbak utility
Backup and restore are executed by Firebird using the gbak utility. The gbak utility may be installed on any computer, even on the database server itself. It can be found in the Firebird bin directory.
gbak is a command-line tool, which means it can be easily called from batch files, shell scripts or scheduler services.
General syntax
gbak <optionen> -user <benutzer> -password <passwort> <quelle> <ziel>
The most important general options:
| –b | Backup (default; does not need to be specified explicitly). |
|---|---|
| –c | Restore (Create). |
| –r | Replace: an existing database is overwritten by the restore. |
| –user <benutzername> | Specification of the user name. |
| –password <passwort> | Specification of the password. |
| –v | Verbose: detailed log of the action currently being conducted. |
| –y <dateiname> | Exports all log messages into the specified file. The file may not already exist at the time gbak starts! |
| –y suppress_output | No log output. |
| –z | Display the gbak version number. |
See also:
Backup
The database must be named as source and the backup file named as the target. The target must be a filename in the computer file system which is executing gbak. If no directory is explicitly named, the current directory is used.
A backup may only be performed by the SYSDBA or the database owner.
Options
| –t | Transportable Backup: A backup is generated, which can be read by all Firebird/InterBase® database, independent of version and platform. |
|---|---|
| Recommended for all backups. | Recommended for all backups. |
| –g | Prevents garbage collection being performed during the backup. |
| –ignore | Checksum errors are ignored during the backup. |
| –m | Metadata only: Only the metadata are backed up, not the table contents. |
| –nt | Non-transportable format: The opposite of –t. Not recommended. |
| –se <hostname>:service_mgr | Uses the Service Manager. |
| Backup: the backup file is created on the database server. | Backup: the backup file is created on the database server. |
| Restore: the restore is made from a file which is on the database server. | Restore: the restore is made from a file which is on the database server. |
| This option must be specified if the security2.fdb is to be backed up. | This option must be specified if the security2.fdb is to be backed up. |
Typical backup example
gbak -v -t -user SYSDBA -password masterkey dbserver:pmm c:\Backup\pmm.fbk
| –v | Verbose output. |
|---|---|
| –t | Transportable format. |
| –user SYSDBA | User name. |
| –password masterkey | Password (the password can be entered in quotes if it contains empty spaces). |
| dbserver:pmm | Database name (pmm is obviously an alias registered on dbserver). |
Another example:
gbak -v -t -user SYSDBA -password masterkey joe:/db/pmm.fdb c:\backup.fbk
Metadata backup
gbak -v -t -m -user SYSDBA -password masterkey dbserver:pmm c:\backup.fbk
See also:
Restore
A restore converts a backup file into a database. The source is the backup file (.fbk file) and the target is the database name. It is possible to overwrite an existing database.
Options
| –c | Restore in a new database. I.e. the database file of the new database MUST NOT exist, otherwise the restore is aborted and an error message appears. Mutually exclusive with –rep. |
|---|---|
| –rep | Replaces an existing database. This database may not be in use at the time of the restore! It can only be performed by the SYSDBA or the database owner. Mutually exclusive with –c. |
| –i | Sets all indices to inactive when restoring. The restore is quicker and indices can be activated singly or together, and recomputed by the activation. |
| –n | Removes all validity constraints from the metadata. This enables data to be restored which violates these constraints and otherwise could not be restored. |
| –o | Restores one table at a time. This can be uses to partially restore databases with corrupt table data. |
| –p <bytes> | Sets a different page size for the new database. The page size must be a multiple of 1024. Values > 16984 cannot be used, values < 4096 are not recommended (and not allowed in Firebird 2.1). |
| –use_all_space | Fills all database pages to 100% instead of the usual 80%. |
Typical restore example
gbak -c -v -user SYSDBA -password masterkey c:\backup\pmm.fbk dbserver:pmm
Restore to an existing database
gbak -rep -v -user SYSDBA -password masterkey c:\backups\pmm.fbk dbserver:/db/pmm2.fdb
See also:
User database security2.fdb
All Firebird service users are stored in the user database, security2.fdb in the Firebird root directory. For a complete data backup a backup of this database should also be made. gbak can be used for this.
The security database can however not be backed up remotely. The Service Manager has to be used. The backup file is generated physically on the database server. If it is created in a released directory, it can then be moved to another location.
For security reasons the security database and any backups of it should not be accessible to non-administrators.
A direct backup of the security2.fdb is however possible, as the Firebird service always has it open. So should you ever need to recover the security2.fdb you will need to follow the following procedure:
- You need a functional user database, so that the service can run. If necessary carry out a new installation. (Here the SYSDBA user is already set up with a password that is known.)
- Perform a restore using gbak, however not directly overwriting the existing security2.fdb in the Firebird root directory, but somewhere else.
- Shut down the Firebird service. In Windows using the Services Manager, in Linux with the fbmgr utility.
- Replace the security2.fdb in the Firebird root directory with the file just created by the restore.
- Restart the Firebird service.