Maybe, but only if you are very lucky! 99.9% of the database backups will be a waste of time, but if you need that 0.1% then all your work will have been worthwhile. You will be grateful for your backup strategy and the added fact that you will be able to keep your current position. Remember, as we say, if you did not take backups (or can’t locate it) when you need one to recover your data, “You can’t buy one!”

VMS backup is an efficient tool, but not recommended for your database backups. The RMU/BACKUP (for Rdb) and DBO/BACKUP (for DBMS) utility is much more efficient, backing up only the pages that are in use and ignoring free space. RMU/BACKUP and DBO/BACKUP also utilize information in the root file to determine the location of all database files. This ensures a consistent backup of the entire database. Therefore, your backup will be faster and the resulting backup file smaller (your restore will also be quicker).

RMU/BACKUP and DBO/BACKUP can be run online (if snapshots are enabled). The root file and all storage area files (your data) are backed up, but the snapshots are not. Incremental backups are fast too as they do not have to read every page. However, if a lot of changes have been made since the last full backup, an incremental backup can actually take longer than a full backup. A good “rule-of-thumb” is, if more than 10% of the database has changed since the last full backup then it is probably more efficient to perform another full backup. It can also mean a longer restore time.

The multithreaded backup facility is standard in Rdb, but is an option for DBMS users (you must add the /MULTITHREAD qualifier).  The multithreaded backup has been optimized to backup to tape – in fact, the more tapes the better! By using multithreaded backup, multiple database areas are backed up in parallel (not to be confused with Rdb’s “parallel backup” feature). This is advantageous if you are running the backup to several tapes on several different tape devices. It can speed up large database backups considerably, if the areas are roughly the same size, otherwise it is only as quick as it takes to backup the largest area (like the WIPLTH_AREA in WorkStream, or the MTRAREA in MANMAN). While optimized for backups to tape, the database backup is also good for disk-to-disk backups.

After Image Journals are optional, but we strongly recommend their use. If you don’t use AIJ’s and your database needs to be restored, then all data since the last backup will be lost. AIJs also allow specific corrupt pages to be restored online using backups and AIJ’s. If there were no AIJ’s, a complete restore would be the only solution (with lost data – not a good option...if you like your job). AIJs allow a roll forward of all committed transactions and the overhead is minimal. In some cases, the AIJs can be optimized before they are applied, making the “roll forward” process very efficient. The AIJ optimization process removes all transactions that were rolled back; multiple updates of the same record are removed leaving only the latest. The database records to be updated are then sorted by db-key making the disk access very efficient.

Things to consider when deciding on a backup strategy: Cost of downtime, size of the database, transaction volumes and tolerance for potential lost data. If you have high-availability requirements, SCI has a better solution than the old traditional full, incremental and AIJ backups – a hot standby database. The hot-standby database is a copy of the production database that is kept in sync with the production database using transactions captured in the after image journal files. With hot standby enabled, a catastrophic failure of the production database does not have to be catastrophic to your business! Besides the obvious “disaster recovery” benefit, our hot-standby solution allows us to offload much of the database maintenance overhead to the hot-standby database.