When was the last time you checked your Abel backup?

If the answer is “I don’t know” then this series of articles is for you.

If you don’t already know, Abel is built in Jade which has a purpose-built object-orientated database. For more information on Jade check out the Jade website.

The first thing I want to stress is that different rules apply when backing up an online database such as Jade. A backup that is performed while the database is active for both read and write access is referred to as a ‘full online’ or ‘hot’ backup. Because the database can be updated during the backup, special begin and end backup records are required to be written to the Jade database transaction journal, to bind the backup operation. So if you’re using third party backup software to backup the .dat and/or current journal files in an online Jade database then, in the words of our Managing Director, “you should be shot!” and I agree.

There are only two acceptable ways to backup an online Jade database:

  • Using an integrated backup application that utilizes the Jade database administration framework.
  • Using Jadecare – Jadecare is a Jade environment management tool produced by the folks at Jade. Click here for more information on Jadecare.

Ok so it’s just been pointed out to me that there are actually 3 ways.. you can also take the database down (ie. closing the Abel application server) and copy the database and journal files manually to whatever location or device you desire. This of course is not an online database backup but its perfectly acceptable.

Within Abel is a comprehensive backup solution that utilizes the Jade database administration framework. Here are a couple of the most important Abel backup features that are crucial to understand and implement:

  • Success and failure notifications: When a backup runs, notifications can be sent to two email addresses and/or two internal Abel users, reporting the success or failure of a backup. Additionally, and independently, Abel constantly checks when the last backup was run; if backups that should have been performed are missed, notifications are sent out reporting this.
  • Journal backup folder: When the current journal file is closed and a new one started, a compressed copy of the closed journal is copied to this folder. This folder should be on a different physical disk to your current database journals. An ideal setup is having your database (.dat files) and journals backup folder on one physical disk/array and your current journals folder on another.

Watch out for Part 2 of this series. In it I will go into detail on how the Abel backup works, how to set it up, how to test it and how the journal file location can affect performance.

Your feedback is welcome so do post a comment if you have a question or something to add.

2 Responses to When was the last time you checked your Abel backup?

  1. J says:

    In regard to:

    “you can also take the database down (ie. closing the Abel application server) and copy the database and journal files manually to whatever location or device you desire. This of course is not an online database backup but its perfectly acceptable.

    …I offer the following qualification- the copy mechanism used may induce some copy errors.

    Callum points out further down in his blog:

    “Within Abel is a comprehensive backup solution that utilizes the Jade database administration framework.”.

    …no doubt this entails using verification checks built into the JADE framework that verifies the correctness of the copy (and reports the result, as he points out further down in the blog).

    That is an important difference between using the framework and not.

    I look forward to the next blog.

    Regards, J

    • Callum Callum says:

      You make a valid point. As you correctly suggested the backup routines provided by the Jade database administration framework can perform verification checks. As each database map file is processed a verification is performed on the data and indexes, consistency checks are performed, as well as checksum information recorded which is used to verify the integrity of the data in a restore operation.

      Its worth mentioning that here in the Abel plant we copy databases fairly regularly and so far (touch wood) we haven’t had any issues as long as the database was taken down cleanly before the copy – by cleanly I mean the database was not in a recovery state. To be sure its clean we will drop the database, then bring it back up (if it needs to go through any sort of recovery it will happen here), then drop it again, then make the file copy.

      But as you’ve pointed out, making an off-line file copy of the database does incur a certain amount of risk and in hind site I shouldn’t have stated that its a perfectly acceptable backup, however, its better than nothing!

Leave a Reply

Your email address will not be published. Required fields are marked *