In “Who is liable for software piracy?” I told you about a tech support pro who tried to solve a database problem by loading a pirated copy of Windows XP on a customer’s machine. In more than 60 comments posted, TechRepublic members discussed many reasons why you shouldn’t pirate software. It’s illegal. It’s unethical. It doesn’t qualify as a problem-solving technique.

I’d like to add a couple more reasons to the list: It’s impractical because you can’t get vendor support for the pirated software, and if you don’t have the CDs, you can’t restore or reinstall if the pirated files get damaged or deleted.

This week, I’ll tell you about a hapless small business owner who didn’t heed my advice. He wound up getting attacked by a worm and had no backup media for a mission-critical application.

When will they learn?
In May 2002, I told you the steps I followed to troubleshoot a Trojan horse that had infected a small business owner’s computer. I gave the owner and his employees my standard speech about safe surfing and safe e-mail, and I recommended buying Trend’s PC-Cillin for antivirus protection.

The owner was grateful and promised that he would buy the software and call me to install it. Unfortunately, he never bought the antivirus software. He did call me some seven months later, and the situation was grave.

The bookkeeper had used QuickBooks in the morning without a hitch. The owner checked e-mail, but when he tried to launch QuickBooks, he got a gnarly error about memory.

When I asked about the e-mail messages, the owner said, “Well, there was one message from a guy I went to school with, and it said ‘language’ in the subject, but the attachment said ‘FoodTV.’”

“And you didn’t think that was unusual?” I asked.

“Well, no.”

When I arrived on site, we ran a virus scan and found that 19 .exe files were infected with a variant of the Klez worm. Among the victims were the executable files for Microsoft Access, QuickBooks, and Quicken.

No backups and no disks either
The users had been backing up their QuickBooks data on a regular basis. However, when I asked about the last time they did a full backup of the hard drive, they had to stop and think. They were sure they’d done one since my previous visit. Then they rummaged through a couple of drawers and a filing cabinet before concluding that the backup must be lost.

“Well, we’ll just reinstall QuickBooks. Where’s your CD?” I asked.

“Um, we don’t have the CD,” the customer said.

The guy who sold this small business owner the computer “threw in” QuickBooks and Office 97 as a little bonus. Wasn’t that special? So the system wasn’t backed up and it wasn’t legal, either.

We made a trip to the computer store, picked up some antivirus protection and a copy of QuickBooks 2003, and we were able to load the QuickBooks data that had been backed up using the previous version.

The client is going to do without Microsoft Access. Meanwhile, we discussed methods for backing up his entire hard drive to a share on the local area network in his building.

The four red flags of backup plans
I can’t hold a gun to my clients’ heads and make them do the right thing when it comes to protecting their systems and their information assets. I have, however, added a new section to my standard lecture about best practices. Here are my four red flags when it comes to backups:

  • No backup at all. It’s hard to believe that any company would still take this risk, but some of your prospective clients won’t have a single backup set for any corporate desktops, servers, or databases. Roll up your sleeves, start the meter running on your billable time, and get the backup plan rolling.
  • Partial but not a full backup. A copy of the company payroll burned to a CD and stuck in someone’s purse is better than nothing, but not that much better. Sure, in the event of a system crash, you can always buy a new machine and reinstall your software from scratch. But restoring from a good, full backup is a lot easier.
  • Backup that’s out of date. The older a backup set is when you restore it, the longer it will take to synchronize the data you restore with the data you have to reenter. Don’t let your customers whine about how much time it takes to make backups.
  • Backup that hasn’t been tested. If you meet a prospective client who claims to make frequent, full backups, ask this question: Have you tried to restore anything lately? Don’t wait until you’re in an emergency situation to test the validity of your backups. Periodically restore at least one file from your backup set, just to make sure the backup is reliable.

The next time you go on a tech support call, ask your customers about their backups. If you see any red flags, take preventive measures right away.

Back me up

To comment on this column, or to share your own advice for successful backup strategies, please post a comment or write to Jeff.