Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people, just like you, are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
Solved

Backup Policy and Documenting Servers

Posted on 2014-01-31
4
405 Views
Last Modified: 2014-03-11
I am currently undertaking a review of our documentation around our corporate backups.

My concern at the moment is that not enough information is documented but I cannot seem to find much information about what a backup policy should document.  
Currently our policy details the following:
What media servers are used
Who is responsible for the backup media
Tape changes - When tapes are exported and imported to the tape libraries
Details on how weekly check sheets are used to document successful, error'd or failed backups.
Details on the backup failure log

Is there anything fundamentally missing from this document, it seems a bit empty to me?

Another problem I have encountered is trying to find out exactly what is being backed up and when.  
I was able to get a list of all our servers from CMDB and a copy of one of the check sheets.  The check sheets show which media is responsible for each backup job.  However, I then had to get another list to show which which servers were getting backed up as part of which backup job.  
This started to get confusing and even more so when the lists didn't match up and it took an investigation from IT to determine exactly what was being backed up and when.  This identified several servers not being backup up at all.
My question relating to this part is, how should this be documented, is this kind of information documented explicitly by most other businesses?  
When I started this process I expected the backup policy document to list all media servers, which media servers were responsible for which backup jobs and which servers were being backed up by each backup job - all neatly documented.
0
Comment
Question by:jdc1944
  • 2
4 Comments
 
LVL 80

Assisted Solution

by:David Johnson, CD, MVP
David Johnson, CD, MVP earned 250 total points
ID: 39825648
In an ideal world everything is blanketed with documentation.  First you have to define the objective, document your objective, and then document the steps taken to obtain your objective. You should have a reporting tool that documents any failures and then resolving this problem should take priority.  You should have at least 3 backups on two different media and 1 copy should be offsite. Tools like System Center Operations Master (SCOM) can help you with the logs and alert you to any problems.  Also remember just backing up is useless without testing the restore process to ensure that you can recover from a disaster. Remember that software is a living breathing item and it evolves over time... so does hardware..... it is constantly shifting item... not much good if your backup media is on qic tape these days... as you can't buy a qic-80 tape drive nor the media any more..
0
 
LVL 20

Accepted Solution

by:
SelfGovern earned 250 total points
ID: 39825730
Your restore process document will also include things like which applications are a part of each backup and where to get the necessary information needed to restore a working version of the program -- serial numbers, account names, passwords.

If you're using encryption anywhere, document how encryption is enabled and how to restore the encrypted tapes.  Also -- where do we find  the keys, if Dear Old George who kept the encryption keys in a special encrypted file somewhere died in the fire that destroyed the data center?
0
 
LVL 2

Author Comment

by:jdc1944
ID: 39846865
Thanks for that.  this information I thought might be mising form the backup policy was:

·        Tape Cleaning.
·        Back-up Device Management.
·        Responsibilities.
·        Media Management.
·        Back-up Checks.
·        Destruction Procedures.
·        Retention Policy.
·        Systems Information.
·        Back-up Schedule.

Is the above normally found in a backup policy?
Also, like the original questions states, I'm still struglleing to find whether the back-up schedule should be documented somewhere, I thought it should be but is this common practice?
0
 
LVL 20

Expert Comment

by:SelfGovern
ID: 39848053
i agree with you about backup schedule.
If you don't have it documented, how do you know if you're doing what is needed and expected?   I ran into a client recently where 30 days of logs showed no full backups in that period.  This was unexpected, and very dangerous...  So yes, document!
0

Featured Post

The Eight Noble Truths of Backup and Recovery

How can IT departments tackle the challenges of a Big Data world? This white paper provides a roadmap to success and helps companies ensure that all their data is safe and secure, no matter if it resides on-premise with physical or virtual machines or in the cloud.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

This article is an update and follow-up of my previous article:   Storage 101: common concepts in the IT enterprise storage This time, I expand on more frequently used storage concepts.
VM backup deduplication is a method of reducing the amount of storage space needed to save VM backups. In most organizations, VMs contain many duplicate copies of data, such as VMs deployed from the same template, VMs with the same OS, or VMs that h…
In this Micro Tutorial viewers will learn how they can get their files copied out from their unbootable system without need to use recovery services. As an example non-bootable Windows 2012R2 installation is used which has boot problems.
This tutorial will walk an individual through configuring a drive on a Windows Server 2008 to perform shadow copies in order to quickly recover deleted files and folders. Click on Start and then select Computer to view the available drives on the se…

856 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question