Approximately 99% of the new clients we've brought on board since 1995 have had little or no documentation of their computer systems. The documentation is at the consultant's house, in his head, or nowhere at all. Sometimes there's a crappy little folder with a printout from the ISP and a couple of piece of paper with chicken scratching. But that's it.
As for backups, our experience has been amazingly consistent: Almost exactly 50% of all new clients have no working backup when they come to us. They might think they have a backup, but it's not working. It's never tested. No one knows when it stopped working. Whatever the case may be, they don't have a working backup.
This article is not about how you design backup strategies. I do have a 12-page white paper on How to Create A Great Backup System in case you're interested. But this article is about how you document your backup.
- Overview -
First, you need a backup. In the big picture, our backups follow some form of the simple data flow demonstrated in the diagram here. We want clients to store data on the server. In cases where they don't or won't, we might institute a Robocopy job to copy data to the server every night.
From the server, we define a backup job to put data on disc, tape, or sometimes the cloud. Our preference is "disc-disc to tape" (DDT) or disc-disc to cloud (DDC). Eventually, we want all data to be moved off site.
It is critically important that you document your backup. I know it seems simplistic, but you really might get hit by a bus and not come in one day.
Documentation takes two forms. At a minimum, you should have a narrative. That means, one simple paragraph for each step of the process. You might also create a diagram. The tools and procedures need to be spelled out so that another competent computer consultant can follow your instructions.
Notice that I did NOT say that the client needs to be able to follow these instructions. Some clients will, some won't. But when you get hit by a bus and the client brings in another competent computer consultant to save their business, that person will understand what you write.
Here's a sample:
- Backup Description
All data is stored on the server in the x:\data directory. No data are stored on the desktops. The only exceptions to this are that the Quickbooks files, financial reports, and personnel records are in the x:\moola directory.
Users "My Documents" folders are not redirected to the server.
Once a week the Backup Exec job "Weekly Full" runs on the server and backs up everything to disc on NAS-1000 storage device. This includes the server O.S., Exchange, etc. Everything. This job is scheduled for 8:00 PM on Friday night. It is normally finished by midnight.
Every night the Backup Exec job "Daily" runs on the server and backs up the Exchange databases and the data drive (This is physical drive "D" on the server). This backup goes to disc on NAS-1000 storage device. This job is scheduled for 10:00 PM Monday through Thursday. It is normally finished by 11:00 PM.
Every night the NAS device is backed up to the Cloud Storage at XYZ Services. Because the weekly full only changes once a week, it really doesn't add any additional data to the daily backups. This backup is scheduled for 1:00 AM on Tuesday through Saturday. Daily jobs normally finish by 5:00 AM. The Weekend Full backup normally finishes Saturday evening.
Files are stored in the cloud storage as simple files and folders. So the backups are just really big files. This synchronization takes place at night and on weekends.
Obviously, your backup narrative will be different from this. But you get the idea.
At some point, we'll talk about the narrative for recovering files (and servers) in a disaster scenario. But, again, a competent technician will be able to figure that out from here.
If you still use tapes, or switch out RDX drives at clients, then you'll also need a sheet for the client to write down when they switched tapes/discs and which one they used. This is particularly important with RDX drives since most backup systems give all drives the same name and don't distinguish them electronically. So a good old labor on the medium is the only way to know which one you want when it's time to restore.
- Implementation Notes -
Implementation here is pretty straight forward. you already have a backup strategy. After all, you've implemented something. Now you just need to write a few paragraphs about what you did.
Have your narrative reviewed by another technician and answer any questions they have. Chances are that a total stranger who wanders in to the office will have the same questions. Integrate these answers into your narrative.
The backup description (narrative) should live in the Network Documentation Binder on site at the client's office. Since you will write it electronically, you can also save a copy on the client's server in the c:\!tech directory and on your own PSA system (Autotask, Tigerpaw, etc.).
Depending on the client, you may want to go over this with them so they understand the backup process. Some clients really get into this stuff. But many clients will just have a blank stare. Don't force them to listen to you. :-)
If you're not used to writing like this, don't fret. Changes are pretty good that you have YOUR way of doing things. As a result, most of your clients have pretty much the same backup system. So you can save a draft description of backup strategies and just tweak as needed for each client.
Remember The Two Great Weaknesses
- Backups that work
Just because you address the backup doesn't mean you can slack off on the documentation. Do both and you'll do your client a huge favor.
Your Comments Welcome.
- - - - -
About this Series
SOP Friday - or Standard Operating System Friday - is a series dedicated to helping small computer consulting firms develop the right processes and procedures to create a successful and profitable consulting business.
Find out more about the series, and view the complete "table of contents" for SOP Friday at http://www.smallbizthoughts.com/events/SOPFriday.html.
- - - - -
Next week's topic: Choosing Pay Dates
Check Out the #1 ranked Managed Services book at Amazon:
Managed Services in A Month
by Karl W. Palachuk
Buy it as a printed book, Audio CD, or ebook!