Spring World 2018

Conference & Exhibit

Attend The #1 BC/DR Event!

Fall Journal

Volume 30, Issue 3

Full Contents Now Available!

Friday, 26 October 2007 07:15

Effective Data Backup

Written by  Alan Lyons
Rate this item
(0 votes)

Over a number of years we have spoken at great length about the need for disaster recovery or contingency planning; the need to have it, and the need to practice it. There is, however, one factor without which all this effort is rendered useless, and that is effective data backup.

What is effective data backup? It is quite simply the backing up of data fields so that you can go to your disaster backup site, restore the files and application software, and be able to continue business as though nothing had happened. Many disaster backup plans are rendered useless, or much less effective, because they rely on data files that are backed up at the wrong point in time.

What is the right point in time? To answer that question we need to analyze what we want to achieve, the ability to carry on as though it (the disaster) never happened. For small disasters such as losing electrical power, we can take our input documents to our backup site and re-input; time consuming, but it works.

For a disaster such as fire or flood, we probably cannot. Therefore we have to look to the critical points in our processing cycles. One of the first critical points, and one which I have always insisted upon, is the backup of data files (all of them) immediately before we do our end of day processing and have them taken 'off-site' as soon as the backup process is completed.

This means that if some disaster occurs after that point in time I can 're-run' the day and produce all the reports and other documentation that have been burnt or are under one-feet of water.

This way the operational staff can continue the next day. Many sites run their data file backups after the end-of-day processing has been completed and send them 'off-site.' Yes, you have the files to be able to continue, but you cannot give the users yesterday's reports because they have been burnt or are under water.

Neither can you re-input the days work because those documents have suffered a similar fate. A second copy of the backups is held in case it is necessary to overcome a 'technical disaster,' such as power failure or hardware failure.

Another critical point is the completion of 'end of day,' or 'end of month', or 'end of quarter' etc. This is critical for those disasters that are generally more of a technical nature.

These backups allow us to continue from some logical point in time that does not involve a re-run of the system for which the users already have their reports. The users simply want access as quickly as possible so they can continue to provide a service. These backups should also be taken off-site.

It is also a good practice to keep a second copy of these backups on-site as well - if the problem does not require going to the backup site (i.e. disk crash that will be repaired within say 2 -4 hours) it can save a lot of time to have the backups available immediately.

A similar critical point is immediately after 'initializing' the system for the next input cycle. For the same reasons as with 'end of day,' these backups are for disasters of a more technical nature, they do not need to be taken off-site as their use is limited.

If there was a major disaster, then the backup from before the previous end-of-day processing started would be used.

Another critical point(s) can occur during the day. This/these backup(s) is/are also for the more technical type of disaster. Where possible one or two backups during the day should be done so as to ease the problem of re-input where required.

They should be readily accessible to the operators, but do not need to be taken off-site. If a major disaster occurred, then the operator could take the backups with him on the way out the door.

Apart from the above mentioned backups, consideration might also be given to backing up the files at other points during processing. These backups might be only 'disk to disk', rather than to tape, which will allow easier restart/recovery required by 'technical problems'. It can save time rather than having to re-run some processing.

While the above relates more to systems that are not 'real time', the basic principles still apply to real time systems. Quite often real time systems have a 'hot-site' backup where the two systems are kept synchronized by the concurrent update of both sites.

Nevertheless, even real time systems have an end of day clean up and reporting cycle. In this case, the 'right time' must be ascertained for backups.

At a minimum it must be done immediately before the end-of-day processing, the users might still need reports to carry on with the next morning. Table 1 sets out the necessary backups; when they should happen; and where they should be kept.

Mr. Lyons is a principal of the IDOM Group and is VP Technology Manager of IDOM Inc. in New Jersey.

Read 2333 times Last modified on Thursday, 11 October 2012 08:18