Firebird Documentation Index → Firebird 3 Quick Start → Protecting your data |
Firebird comes with two utilities for backing up and restoring
your databases: gbak and
nbackup. Both can be found in the bin
subdirectory of your Firebird
installation. Firebird databases can be backed up while users are
connected to the system and going about their normal work. The backup
will be taken from a snapshot of the database at the time the backup
began.
Regular backups and occasional restores should be a scheduled part of your database management activity.
Except in nbackup's lock mode, do not use external proprietary backup utilities or file-copying tools such as WinZip, tar, copy, xcopy, etc., on a database which is running. Not only will the backup be unreliable, but the disk-level blocking used by these tools can corrupt a running database.
Study the warnings in the next section about database activity during restores!
More information about gbak can be found here (HTML and PDF version, same content):
The nbackup manual is here (again same content in HTML and PDF):
The following sections constitute a summary of things not to do if you want to keep your Firebird databases in good health.
Firebird is installed with forced writes (synchronous writes) enabled by default. Modifications are written to disk immediately upon posting.
It is possible to configure a database to use asynchronous data writes – whereby modified or new data are held in the memory cache for periodic flushing to disk by the operating system's I/O subsystem. The common term for this configuration is forced writes off (or disabled). It is sometimes resorted to in order to improve performance during large batch operations.
The big warning here is: do not disable forced writes on a Windows server. It has been observed that the Windows server platforms do not flush the write cache until the Firebird service is shut down. Apart from power interruptions, there is just too much that can go wrong on a Windows server. If it should hang, the I/O system goes out of reach and your users' work will be lost in the process of rebooting.
One of the restore options in the
gbak utility (gbak
-rep[lace_database]
) allows you to restore a gbak
file over the top of an existing database. It is possible for this
style of restore to proceed without warning while users are logged in
to the database. Database corruption is almost certain to be the
result.
Notice that the shortest form of this command is
gbak
-rep
, not
gbak
-r
as it used to be in
previous Firebird versions. What happened to gbak
-r
? It is now short for gbak
-recreate_database
, which functions the same as
gbak
-c[reate]
and throws an
error if the specified database already exists. You can force
overwriting of the existing database by adding the
o[verwrite]
flag though. This flag is only
supported with gbak
-r
, not
with gbak
-c
.
These changes have been made because many users thought that
the -r
switch meant restore
instead of replace – and only found out otherwise when it was too
late.
Be aware that you will need to design your admin tools and procedures to prevent any possibility for any user (including SYSDBA) to restore to your active database if any users are logged in.
If is practicable to do so, it is recommended to restore to
spare disk space using the gbak
-c[reate]
option and test the restored database
using isql or your preferred admin tool. If
the restored database is good, shut down the old database (you can use
the gfix command-line tool for this; see
http://www.firebirdsql.org/manual/gfix.html
or http://www.firebirdsql.org/pdfmanual/Firebird-gfix.pdf).
Make a filesystem copy of the old database just in case and then copy
the restored database file(s) over their existing counterparts.
Firebird Documentation Index → Firebird 3 Quick Start → Protecting your data |