Backing up costs money. Casually deciding that everything on every system will get backed up every night will cause costs to soar as new storage for backups must be purchased, and the need for network bandwidth increases. At the same time, backing up too little on a system will cause problems when files that were excluded need to be restored.
Authors of a backup policy need to determine what data is important to the business and what the impact is if it is lost, damaged, or otherwise inaccessible. Each repository of data must be considered: traditional file systems, storage area network (SAN) storage, database servers, mobile devices, and grid storage.
From there, it must be decided how ephemeral each piece of data is, that is, its life cycle. How often does the data change? Its life cycle will help determine the backup cycle. As a technologist, you should also consult with your company’s legal department. It may be a legal requirement that certain data is backed up and retained for a certain period of time.
It’s valid to find that certain data should be excluded from a backup. Graphics workstations often contain large scratch files. Depending on company policy, users may have personal files on their work computers. Determining which data is to be backed up is called the scope.
Only after creating a policy should you evaluate and specify specific hardware and software for backup. Regardless of the ultimate strategy chosen, the plan must include provisions for routinely testing backups. Backup destinations cannot be black holes into which data disappears. Backup logs need to be checked after each backup run.
Tests need to be performed to validate existing backups. The worst time to find out that a backup was not successful is when trying to restore data for real. The following table lists potential questions to ask when creating a backup policy.