I hate to bring up a subject again that I am compelled to bring up so frequently, but there are still some of you out there not taking proper backups. Sometimes taking good backups not only means doing the backup operation itself, but also ensuring that the restore operation works OK. Here is a story.
I have a friend and client whose PC failed the other week. It was a motherboard problem, and in those cases the hard drive and data are usually OK, as in this case it was. Since the PC was old, the resolution should have been a simple procedure: get a new PC, take the hard drive out of the old PC and put it in an external hard drive enclosure, plug the external HD into the new PC and copy the data. You then install the programs, start them up, find the old data, move it to where it is supposed to be, and you should be good to go. But we hit a big snag.
My client was using a personal information database program, which internally used the MySQL database to store its data. MySQL is one of the most popular database systems around and in use in millions of PCs. It is usually fairly reliable and stable - but perhaps not in this case.
MySQL has an internal backup capability, which the program utilized. So far, so good. But when my client did a program backup, what was really happening was that it was invoking the internal backup capability of MySQL. This leaves a backup file in a not very obvious place (the MySQL folder in Program Files). The first problem is that my client assumed that a backup was being done, and never copied the backup file to a CD. Since she didn't even know where the file was, backing it up to CD would have been difficult anyhow.
The second problem was that the format of the data in the backup file was of the type where the initial backup contains the original data, but only what are called "differential" backups are done after that. Differential backups contain only data that has changed since the original changed and so are smaller. Each time my client did a backup, it just added another differential backup record to the same backup file. Eventually what was a relatively small amount of data grew to an 83 MB file.
After consulting with tech support for the program, I found out that due to the nature of MySQL we could only restore data from a backup file - just moving the original database files from the old hard drive would not work. OK, so we went to load the backup file, and got a fatal program error. Back to tech support again, who informed us that the file was corrupt and that my client had lost all her data!
Needless to say, she wasn't too happy about it. But my knowledge of database programming made me believe that the data could be recovered by an engineer or programmer who knew the database format and had a full set of diagnostic and repair tools. Luckily my client had a contact name at the program corporate headquarters and we were able to get someone who sympathized with our plight. She uploaded the file to her computer and sent it to one of the engineers for recovery. The engineer was in fact able to recover all my client's data, and my client (and I) are now happy campers.
So what lessons did we learn here? First of all, you need to know where your backup data is (i.e. what folders and files) and ensure that it is viable by testing it once in a while. Second, you need to backup to an external hard drive or CD if the program backup just puts the data back on the C drive. If my client's hard drive had crashed we would have had no backup data.
And, finally, sometimes it pays to not accept the first answer you get from tech support. If you feel you are right, keep on escalating until you get someone who can help.
(Bob Seidel is a local computer consultant in the Southport - Oak Island area. You can visit his Website at www.bobseidel.com or e-mail questions or column ideas to him at bsc@bobseidel.com. For specific inquiries, please call Bob Seidel Consulting, LLC at 278-1007.)