The magazine of the Melbourne PC User Group

Verify or else: A boy's own adventure
with CD-ROM backups

Michael Marquart
micm@melbpc.org.au

Have you ever thought about backing up your precious data from your hard drive onto a CD-ROM? I did more than think about it. I did it. More than once. I've had six copies of my hard drive made. It's been an experience (not all good.) In fact it was one of those bad experiences that prompted this article, in the hope that other members might benefit. Even though it hasn't been trouble free, I'm glad I did it. I would even recommend it, but only if you know the potential pitfalls, and what you can do to avoid falling into them yourself.

Chapter one, in which our hero burns his first one...

I was very excited about having my first CD-ROM back up of my hard drive. I looked at the files and subdirectories and all looked fine. Well, not excited really. I was elated! Now if my hard drive fell over in a heap, I wouldn't have to spend weeks trying to recreate all those batch files, directory structures and custom configurations. Nor would I have to re-install all those applications and games from floppy disks. All I would have to do, I thought smugly, was shell out for a new hard drive and copy my CD-ROM onto it. Wunderbar!

Chapter two, in which our hero is burnt by his first one...

My self-satisfied state was short lived. Not long after taking delivery I was showing of my newfound pride and joy to a friend. After copying a small utility from the CD-ROM to his hard drive, for the purpose of showing him how easily I could restore a humungous (but rarely used) program that was gobbling up precious hard drive space, I tried to execute the utility. The PC hung.

"No problem," I thought to myself, "PCs hang every day for no good reason! I'll just reboot..." Well, the same file hung the PC again. And again.

I thought, "That file works on my PC, Hmmm.. I'll try another one." You have probably guessed that the next one didn't work either. Now I was perplexed. Could it be that my delight in technology was ill-founded?

Chapter three, in which our hero puts on his Sherlock Holmes hat...

When I arrived home, I compared the original file with the defective CD-ROM one. The first two bytes were different! I examined the code in the .COM file and discovered that the first instruction was a jump to just past the end of the file. Curious, I thought, and then...Eureka! I recalled that viruses commonly change the first byte of a program to a jump to the virus code - which is tacked onto the end of the file - when the virus installs itself.

I continued my investigation using the latest version of McAfee's Virus Scanner on the CD-ROM. I found a large number of .COM and .EXE files flagged "may not be executable!" but no files were infected, and a full scan of my hard drive showed no irregularities.

It just so happened, that another Melb PC member had also had a CD copy of her hard drive burnt by the same vendor, at the same time I had mine done.

I rang her and asked if she had used her CD-ROM. No, She hadn't. A quick scan of her CD-ROM and, lo and behold, there was the Junkie Virus, in all its splendour!

I don't know which of us was more surprised. A scan of her hard drive showed it to be as clean (virus free) as mine was. The only logical conclusion, my dear readers, was that the infection had to been introduced during the making of the CD. The vendor's system must have been infected with the virus - which had been discovered in time to disinfect mine (albeit, inadequately) but not before it had infected the other member's CD.

Chapter four, in which our hero confronts the vendor...

I queried the vendor and he swore that he had no viruses. He did however, offer to burn me another CD-ROM for just the cost of the CD-ROM itself (his generosity knew no limits.) Because I was enamoured of this new technology (and I'm too much of a gentleman to argue against a bold-faced lie) I accepted his offer. I took my hard drive back to him and he burnt another CD for me. I left (wiser for the experience) with my first usable CD-ROM backup.

I decided then that a casual comparison of the hard drive and CD was not sufficient to ensure that a CD-ROM backup would be up to the task for which it had been created. Thus I embarked on a programming project that would verify that the data written to my CD-ROM was in fact an exact duplicate of the data on my hard drive - but more about that later.

First, to allay any fears that you, my readers, may have that CD-ROM backups do not work, I must confess, that since that initial experience I have had six CD-ROM backups burnt. All of them have been perfect, save the first. And the last.

Chapter five, in which our hero learns another lesson...

For the sixth back up CD I switched to a vendor closer to my home and who had a faster CD-ROM writer. I thought it would be easier and faster to switch, rather than remain with the vendor I had been using. (This was not the original vendor, I didn't go back to him after the initial virus experience.)

You, dear readers can probably predict the outcome, at least in part. So I'll cut a long story short and jump to the conclusion. The CD-ROM I received had seven bytes changed (over the entire CD-ROM. One of them was in a 50 MB archive which rendered that archive useless.

I notified the vendor of the problem. He offered to burn me another one (after destroying the first one without my consent). His second attempt also had a seven-byte discrepancy, which to my mind indicates a fault in his equipment or software.

When I again queried him about the CD, he told me, "Well, you are the first person to complain."

To which I thought, perhaps others place blind faith in the technology. Whereas I, having once been burnt, test every backup to ensure that it in fact does what it has been created to do. After all, how many shiny coasters do I really need?

Chapter six, in which our hero puts what he has learnt to work

Learn from my experience. Always test your backups to ensure that you can indeed restore your files. That's easy to do if you're testing a backup of a single file or directory. When you're talking about a CD-ROM backup of your entire hard drive, it's easier said than done, unless, of course, you have the assistance of the program I told you there would be more about later.

It's a batch file that uses tools that come with MS-DOS 5 and Win 95 (except perhaps QBASIC, although that can be dropped in from a prior version of MS-DOS). I developed, tested and have used the batch file with MS-DOS 6.22. I have also tested it in a DOS window in Win 95.

The batch file compares every file on one drive, with the same file on another drive. It uses FC (the MS-DOS file compare function). It counts down as it goes through the files. When the process is complete, it produces a full report and a condensed report. It's written with the assumption that the two drives have the same directory structure. But you can give it a starting offset, and it will compare a subdirectory branch.

Where is this batch file, you ask? Its format makes it unsuitable for printing in PC Update, because of the length of the lines (in excess of 120 characters) and the size of the file. It's about 5 KB, which as you might imagine makes it vulnerable to typos. So instead I will upload the file to the Melb PC BBS as VERIFYD1.LZH. (Long-distance subscribers will need to wait to download it from the Melb PC web site when the magazine is uploaded).

Chapter seven, in which our hero shares one final bit of wisdom

Whether you back up to floppy disk, another hard drive, tape, Zip drive or CD-ROM, you should verify that data. Oh, and don't forget to scan the backup for viruses if the backup was done on a machine other than your own. You can skip that step if you use your own equipment because you always scan any new program prior to executing it. Don't you?

May your PC never fail. Enjoy!

Reprinted from the June 1997 issue of PC Update, the magazine of Melbourne PC User Group, Australia

[About Melbourne PC User Group]