Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 418
  • Last Modified:

Backup Policy and Documenting Servers

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
jdc1944
Asked:
jdc1944
  • 2
2 Solutions
 
David Johnson, CD, MVPOwnerCommented:
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
 
SelfGovernCommented:
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
 
jdc1944Author Commented:
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
 
SelfGovernCommented:
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

Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now