Any company that relies on their data and IT infrastructure needs to take a formal approach to planning, managing and monitoring their backup system. Even in smaller companies, where an ad-hoc/informal approach seems sufficient, there are considerable benefits to be gained by taking the time to do things right.

One of the factors that leads to a delay in adopting more formal processes within just about any environment is the time required to develop the documentation which helps to define those processes.

To assist companies in adopting a more formal approach to their backup environment, I’ve developed some templates based on recommendations in the book.

Acceptance Test Procedures

Deploying a new backup system requires rigorous testing to ensure that data and systems really can be recovered from when required. You templates here in the following formats:

Building a procedure/plan that can be instantly used by any company is next to impossible. What the above sample procedures should do however is to introduce one approach to formalised testing, and give sufficient structure and examples to allow a company to adopt the template for their own needs.

Test Register

In order to have an audit trail, and a log of periodic tests conducted, maintenance of a test register is paramount. This should leverage both ad-hoc tests, as well as the tests from the formal acceptance test register, in order to cover as many situations as possible. You can find here templates in the following formats:

Recovery Request Form

While smaller companies will approach recoveries in an ad-hoc manner, for larger companies, and companies requiring compliance to data integrity and security regulations, it will be necessary to formalise the process of requesting a recovery. This allows for larger volumes of recoveries, as well as the auditing of who requested what, and when. You can find below templates in the following formats:

New System Form

Too often, backups are considered as an afterthought once a system has gone into place – sometimes even after it has been running in production for a while. This new system form should at least be a starting point for companies wanting to better integrate backup preparedness into change control. Templates are below in the following formats:

Backup Software Functionality Checklist

In chapter 11 of the book, a sample checklist is provided that may be used when evaluating multiple backup products. That checklist is primarily designed for in-house comparison by staff. The checklist below is a sample of the style of document that may be used to map vendor cited functionality, but should be adapted to suit your local needs. Templates are in the following formats: