Welcome To The Home Of The Visual FoxPro Experts  
home. signup. forum. archives. search. google. articles. downloads. faq. members. weblogs. file info. rss.
GENERAL BEST PRACTICES >>  BACKUPS - THE BARE MINIMUM

  Ken Murphy
  Where is Ken Murphy?
 Springhill
 Canada
 Ken Murphy



What is a backup?

For the most part, a backup is an expensive procedure (it costs lots of time and effort) that, in the best of all worlds, will never be used. A backup is going to be a major component in your disaster recovery process. If you never have a disaster (and one hopes that you never do) then the backup would be completely redundant and useless. On the other hand, if you do run into a disaster, your backup could be worth millions of dollars.

This leads to two basic goals for the backup. First, the backup should take as little time and effort as possible and second, the backup must be fully capable of allowing complete recovery to the point of the last backup.

How to reduce backup costs. This is relatively simple. You purchase a good backup software, and schedule it to run, unattended every night. Obviously, if you are in a very large organization, you may need to have an operator who can load tapes, insert blank disks, etc. For other larger organizations, a completely redundant mirror may be the way to go. For smaller companies, your choice might be to simply use MS Backup.

Depending on your organization, you may need to purchase some hardware to go with your backup software. Tape drives, removable hard drives, CD and DVD burners are options that you may wish to consider.

How to ensure that your backup will allow you to recover.

There is only one way to know for sure - you test it. You would be amazed at the number of people who simply assume that their backup will work. If you have not tested your backup, you could be in for a rather nasty surprise. The best way to test your backup is to restore it to a new machine. In a worst case scenario (a fire, for example) you will need to restore your backup to a brand new machine. The next time you buy a new machine, go ahead and restore your backup. Did it work? How much time and effort did it take?

A Backup Begins With A Plan:

As with anything, failing to plan is planning to fail. What are your objectives? What does your company consider to be tolerable in terms of recovery costs? What do you need to recover and what would be "nice if we could recover it?" Begin by developing a disaster recovery plan. This will lead you to the answeres you need. Google "Disaster Recovery Plan" if you are unsure of how to create your own.

At a bare minimum:

1 - You will need to backup your server's system state. In the event of a fire, you buy a new server, load up Windows Server software and then restore the system state. Even in a small organization, this will save you about a day of setup time.

2 - Backup your Database directories, your EXE files and most importanly, BACKUP YOUR DEVELOPMENT DIRECTORIES. I ran into one company where the the disk drive containing the development directories died. It took that development team about a year to recover from that disaster - no backup. ReFox can help when all you have left is the EXE, but do you really want to rely on ReFox?

3 - Backup your Exchange Server data. Email, Shared Exchange folders and shared calendars all contain mission critical data. You don't want to be the one who has to go to the President of the company with the bad news "Sorry sir, but your email is gone."

4 - Backup everybody's "My Documents." Again, these directories contain mission critial information. In a Windows Server environment, you can have the My Documents folders stored on the server with a copy automatically stored on the user's C drive. Each time the user logs off, these folders are synchronized.

How often do I backup?

Most organizations will do a nighly backup (we do.) In the event of a disaster, we can recover to the previous backup. This means that at most, I would loose only one day's work. For our organization, that is an "acceptable" level of risk.

On the other hand, I will also backup certain tables just prior to bulk updates. For example, we have a procedure that processes preauthorized payments that are automatically deducted from our supporter's bank accounts. As can be imagined, when we run this process it affects a lot of records in a number of tables. For this reason, we do a special backup of the relavent tables just prior to the update. In the event that the update fails, we can recover to just prior to that update. For these "special backups" my method of choice is the SELECT command.

SELECT * FROM MyTable INTO TABLE [Path2BackupDir\MyTable]


In the event of an update failure,

USE MyTable IN 0 EXCLUSIVE
SELECT MyTable
ZAP IN SELECT([MyTable])
APPEND FROM [Path2BackupDir\MyTable])


In the event that the update succeeds

ERASE [Path2BackupDir\MyTable]


How many backups do I keep?

You need a minimum of 2 backups. You need the current backup and the previous backup. If your current backup is lost or for some reason, cannot be used, you need at least the previous backup. You may be able to recover from the previous day's backup. I recommend a series of backups, one for every working day of the month. At the end of the month, you can begin reusing tapes or rewritable CD's. I typically keep the final backup for the month as it contains a picture of the organization "as at month end." Your comptroller will love you for that one. It is amazing how many times I have been asked "can you show me what this record looked like a the end of the last fiscal month?" during an audit.

Where do I store my backups?

A few days ago, I walked into a new customer's office and found that they had a complete daily backup for each day for the past year. All of these backups were nicely filed in a specially build cabinet with a drawer for each month. The SysAdmin was very proud of his backups - he even told me that he regularly tests his backups. Once a month, he wipes a computer and does a complete restore to that computer. I asked him "So if there was a fire, you could recover to yesterday evening?" He thought he could, and when I asked him to prove it, he walked over to his backup cabinet and pulled yesterday's backup. I told him to stop. "That backup doesn't exist anymore. It was burned in the fire!" BACKUPS MUST BE STORED OFF SITE! If you wish to keep a copy of a backup onsite, that is just fine, but if that is your only backup, it had better be stored offsite. We take ours to the bank and we store them in a safety deposit box. For small organizations, simply have a trusted employee take the backup home - anything - just get the backup off site. In the event of a fire, you will be able to recover.

Hurricane Katrina taught me a lesson. Storing your backups off site but in the same city may not be enough. We have another office located 200 km from the server and we have a daily courier run. Our backup now goes into the courier bag, is shipped to the other office and is stored in a bank's safety deposit box located 200 km from our office. (They send their backups to us.)

Hope this helps.

FEEDBACK

nyron williams @ 12/15/2006 7:23:26 PM
Excellent suggestion as always
My ratings to you



Your Name: 
Your Feedback: 

Spam Protection:
Enter the code shown: