Backups — Documentation

With most every client I take on there are two weaknesses I can count on encountering. Documentation and Backups.

In the years I’ve been operating as a consultant, new clients have had little or no documentation of their computer systems. The documentation is at the previous consultant’s house, in his head or does not even exist. Sometimes, there is a folder or binder with a few sheets of paper containing ISP settings, maybe, and sometimes a few pages of various chicken scratches that make no real sense without having been there, at the time they were made.

As for backups, I’ve found that no more than 30% of new clients have no working backup when they on-board with 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 is blog post is not about creating a useful and sustainable backup solution. It is about documenting the backups, processes and contents.

First, everyone needs a backup. Businesses more so than individuals, because data is both a business’s most valuable and most vulnerable asset. In a perfect environment, the users work on their local machine, saving their work, locally. The workstation then synchronizes those changes with the server. The server then runs a backup to an external storage device, such as NAS (Network Attached Storage) unit or external USB hard drives. The server also manages a cloud based backup, as well. This helps ensure that a backup copy of the data is off-site as well.

It really is critical that these backups are documented. Your service provider (me, I hope) can provide documentation to recover a file or folder accidentally deleted, so users can quickly recover needed files. But also, in the event of a major issue, if your normal provider is not available, the documentation can be critical in getting your system fully restored by a temporary provider.

Documentation from Indy’s I.T. Department takes two forms. At a minimum, you will get a narrative. A simple paragraph for each step of the process. Maybe an over-all diagram. A list of the tools used so that another competent consultant can follow the instructions.

Here is an example:

  • Backup Description

    All user data is stored on the server at U:\User_Data. No data is stored on the desktops, with the exception of financial and personnel files. They are stored on R:\Quickbooks, R:\Financials and R:\HR, respectively.

    Users ‘My Documents’ folders are not redirected to the server.

    Once a week, Windows Server Backup runs the “Weekly Full” job to rotating 1TB external USB 3 HDD’s. This kicks off every Saturday at 2100. Normally, this is finished between 0200 and 0300 on Saturday.

    USB HDD’s are swapped by the Office Manager every Monday morning.

    Every week night, the server performs an incremental backup to the previous week’s full backup drive. These backups start at 2100.

    The server also has Cloud Storage Backup Service running on it. As the users save files to the server they are synchronized as a background process to Cloud Storage Backup Service. The USB HDD’s are excluded from this service.

Naturally, the backup narrative for your business will be different, but this is an example to provide a simple description.

This is a pretty straightforward example, though it does not cover/include details for any databases or line of business applications that need to be protected up, as well. This piece of documentation, when completed as a full backup and recovery detail set should be stored in a binder at the client location, an electronic copy on the server in a consultant’s directory and I like send an e-mail copy as well to myself and the point of contact at the client site. This means the details are ALWAYS available, somehow, somewhere.

A working backup is great, but if no one knowns how to access it in a time of need, then there really is no backup.

About the Author:

Leave A Comment