Database recovery for Firebird and InterBase®
Backing up your Firebird or InterBase® server is standard practice, but without a proven recovery process, the backup could be useless. Use this checklist to get started.
Never copy a database file at file system level during runtime. This could result in physical database file errors in both the copied file and in the original database file.
Always use gbak to create a server-based backup file of your database. The resulting file can be copied wherever you need it
Firebird also provides
nbackup to improve the speed for large databases, but since it sometimes needs more space than required, it should only be used with large database files (e.g. over 50
GB) that have little data manipulation.
Depending on the speed of the server and the Firebird/InterBase® version used, the backup process takes only a few minutes per gigabyte, so in most cases a full backup using gbak can be recommended.
The restore process of a backup file should always be tested, as there are a number of database errors, which are not apparent while the backup process is running, but which prevents a successful restore.
To minimize lost data in the case of a failure, a database backup can also be made several times a day. Firebird and InterBase's multigenerational architecture allows a backup to be run while users are connected and working on the database.
If your backup takes, for example, just 5 minutes, you can schedule an hourly backup to ensure that, should your system crash, only data manipulation performed within the last hour is lost.
We recommend restoring your database immediately following the backup onto a separate server, which can be accessed and used by all clients immediately in the case of the main server failing.
Prepare yourself for the worst case scenario:that your server has an unrecoverable error and no experienced administrator is on hand to restore the system on a replacement server. You can set up a backup database server with two network interface cards, where the second disconnected interface card uses the same IP as your regular server. As long as the main server operates without any problems, it is not connected to the network, so there is no conflict and the backup/restore process uses the first network interface card. When the main server crashes, you just have to switch the network cable from the main server to the backup server and all clients can use the backup server using the same IP based connection string.
Do not rely only on RAID technology, we have received several databases from customers that were the result of a RAID system failure, for example two disks crashing at the same time. Sometimes a simple hard disk is more reliable.
Always check if the backup has been performed successfully, for example, have the log file automatically sent by email should an error occur.
The use of a database shadow on an external USB drive is another way to improve the recovery time.
How to automate the described operations? If you simply need the basics to automate backup restore services, we recommend using the IBExpertServerTools available here, price EUR 79.00 per server. This includes the same IBExpertBackupRestoreScheduler, that is also available in the IBExpert Developer Studio. Beside other extremely useful tools, this module allows very flexible backup and restore configurations. For less experienced users, we offer the RemoteDBA service. When ordering this, we will set up all required tasks on your server using a remote desktop software and monitor the sucessful execution of all tasks for you. The price starts at EUR 249.00 for an annual server check. We can also set up all the technology described here using our support hotline or as part of individual workshops at your site. Simply ask sales@ibexpert.biz for a quote or order the products online.
Although we have only covered the basics of Firebird/InterBase® database recovery in this article, these tips can help you make a start in the right direction, and certainly save yourself a lot of headaches should problems arise.