DO YOUR BACKUPS WORK?

An interesting question, but not funny to those users who cannot restore data at vital times. Changing tapes may be a daily ritual, but actually checking to see if they are successful may not be. Have you tried yours lately?

Backups are your responsibility, and a very important one at that.

No matter what happens to a server, either fire, theft, physical failures, or Operating System corruption’s, data backups should enable a complete recovery.

Without this protection, the consequences could be catastrophic.

Tape drives like any media storage device (Video, Audio and Camcorders) need regular cleaning, monthly if not fort-nightly. Cleaners can be purchased from most stationary suppliers, and are effective in the life span of both physical drives and media.

It is recommended that tapes do not get recycled for periods longer than 12 to 14 months.

A common problem is data exceeding more than one tape. An output would be written into the backup log asking for a second volume to be inserted, but because the procedure is done overnight and automated, you will not be able to replace the tape. If this scenario happens, then you need to either restrict the amount of data being backed up, change the drive or implement compression software.

(Backup over runs can be minimised by good housekeeping, check on a regular basis that there are no stuck processes with temporary files open, or that temporary files have been left on the system by users crashing out of processes, remove the transaction log file on a regular basis, this can become massive, and for most companies it will have little value beyond the current week.)

ISTUG recommends that you have a rolling backup regime. A typical process could be:-

Four tapes marked Week 1 Monday to Thursday.

Four tapes marked Week 2 Monday to Thursday

Five tapes marked Friday Week 1 to Friday Week 5

Some companies may in addition wish to carry out system backups prior to carrying out period end processing, in this case further tapes will be required for each month Jan – Dec. This can become very complicated if the N/L, S/L, and P/L are dealt with at different times. The purpose being to see in the event of recovery, through their physical reports the best month to roll back to.

(Companies should as a part of there internal Disaster Recovery Program ensure that all system backups are stored off site in a temperature controlled environment free of any magnetic interference, and transportation of tapes should be in magnetic shielded containers.) It is no good going to all the trouble of making backups, if they are going to be ruined during transportation or storage.

As well as data backups, system backups are essential. Failure to backup your operating system can result in several days downtime rebuilding your personalised environment. Some Operating systems have bootable recovery features, AIX mksysb, others like SCO UNIX have third party utilities such as Lone-Tar with cactus Airbag. (The same rules about storeage and transportation apply.)

AIX users should have at least two if not more mksysb backup tapes. These are essential not only for recovery, but also diagnosis of a crashed system. Failure to have these tapes may result in a system rebuild when a quick simple fix could have been implemented.

Unix utility product Lone-Tar performs Bit Level backup and verification, plus data compression to double tape drive capacity. The Airbag utility (SCO UNIX I LINUX ONLY) allows you to create boot disks, which will give you the immediate ability to recover your system to new hardware. The Lone-tar product is available on all versions of Unix and is far superior to generic backup utilities (tar I cpio). It is also menu driven, which allows the control of backup and system recovery to be in your hands.

NT systems with SQL databases like CS/3 should have a backup utility with specific SQL add-ons. These will shutdown the SQL engine to allow archiving. If you wish to directly backup SQL databases, the engine must be stopped.

If you do not have a specific backup tool and add-on's to automatically stop the SQL Engine, then you will need to configure SQL itself to output the database to a backup file on hard disk. This will allow archiving by generic backup tools.

Never assume the backup will work.

or

The data backups can be read.

Always make sure.

(It is a good idea to work closely with your reseller on this issue, build a clause into your support agreement, get them to offer a system for you to actually do a system restore on an annual basis to prove your system recovery procedures.)