Friday, September 30, 2011

SOP Friday: Documenting backups

As I've pointed out in The Network Documentation Workbook and in many presentations, there two weaknesses at virtually every new client we take on. The first is documentation and the second is backup.

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

- Documentation

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!

5 comments:

  1. Oh My Goodness! I L-O-V-E this article. as a gal who frequently audits and then documents policies and procedures for small business (and who geeks out over workflow), I salute you sir!

    The BEST thing every small business can do is document their procedures. I call it the "McDonalds" book. Because if it's a bus or your admin/IT staff runs off to Key West and never comes back, that business still has to run without them.

    The highest form of service a small business computer consulting firm can provide is teaching their clients exactly what they do. It makes the consulting firm more valuable.

    Jessica Chapman Clark, http://roomtobreathe.org

    ReplyDelete
  2. As per usual, great stuff Karl.

    The only comment I have is that I dislike the focus on backup. It's always been about the recovery process. Always has been, always will be. If you focus on the recovery processes you'll always implement an appropriate backup system.

    ReplyDelete
  3. Thanks, Jessica.

    Chris: I agree. That's why I say "If you can't restore from backup, then you don't have a backup."

    ReplyDelete
  4. Karl, Thanks for a great article as usual. The link for your white paper on creating a great backup system gives a 404 error.

    ReplyDelete
  5. Thanks for the heads up.
    The corrent link is: http://www.smbbooks.com/categories/whitepapers.htm.

    I corrected this in the post.
    - karlp

    ReplyDelete

Feedback Welcome

Please note, however, that spam will be deleted, as will abusive posts.

Disagreements welcome!