The importance of data backup policies and what to include
It's important to document your data backup and recovery policy. Take the first step and download our template and use this structure for developing other IT policies.
Your IT organization regularly backs up data, systems, network configuration data, databases, security parameters and other information resources. But does it have data backup policies?
Most likely a backup schedule is available that conforms to the overall backup process. The schedule, which should map to the backup policy, defines what should be backed up, types of backups to be performed, storage locations for backed-up data and other resources, frequency of backups, backup media to be used, time frames for executing backups, duration of backup storage, recovery of backed-up data and systems, and a means of confirming that backups were successful.
Assuming your IT organization doesn't have a formal, documented data backup policy, begin preparing one that is consistent with good practice, is compliant with relevant regulations and standards, and will pass audit scrutiny. The data backup policy template included below can assist in preparing the policy.
What is a backup policy?
A backup policy sets forth the importance of data and system backups, defines the ground rules for planning, executing and validating backups and includes specific activities to ensure that critical data is backed up to secure storage media located in a secure location. This ensures that information from business applications such as Oracle, Microsoft SQL, email server databases and user files is copied to disk and/or tape to ensure data recoverability in the event of accidental data deletion, corrupted information or a system disruption. The policy's default protection scheme ensures the recoverability of servers, network components and other infrastructure devices, as well as critical applications, databases and important files.
This article is part of
Create your data backup strategy: A comprehensive guide
For example, a default backup policy for all application data might be a nightly backup to tape from Monday through Friday. In this case, one set of tapes is kept on site to facilitate local recovery and a second, duplicated set is sent off site for storage in a secure location. Critical business data might be further protected by policies that specify more dynamic backup activities. These might specify that, in addition to nightly tape backups, point-in-time snapshots of data should be taken and replicated at frequent intervals during the business day to provide rapid, granular data and application recoverability. This is essential for disaster recovery, business continuity and information security.
Backup policies should also include the recovery point objective (RPO) metric that defines how long data should be stored -- e.g., aged -- before it must be backed up again. RPO values -- usually a time frame such as seconds or minutes -- are defined by business system and data owners and might be reviewed and approved by senior management. The shorter the time backed-up data is stored before it's needed for a recovery situation, the greater the cost of backup and storage. For example, a very short RPO, such as 10 to 30 seconds, means that mission-critical data -- and computer systems, VMs and other resources -- must be frequently backed up, most often in real time. This means technologies such as data mirroring and/or replication, suitable storage resources and high-speed low-latency network resources must be used to achieve RPO goals.
In general, a backup policy baseline process specifies capturing an initial full backup of data onto disk and/or tape, followed by a series of intervening incremental or differential daily backups.
Regardless of which method is used, at a minimum, two backup copies should be maintained: one to enable on-site recovery and a second copy for vaulting to a secure off-site facility. That way, if the data center were destroyed by a flood, fire or some other disaster, the off-site copies become the recovery resources for returning to business as usual.
In this article, the terms incremental and differential backup are used generically. Note that some vendors use these terms to describe entirely different backup methodologies.
What should be backed up?
In practice, data files, databases, utility programs, network software, cybersecurity software, network perimeter software -- e.g., smart firewalls, intrusion detection/prevention systems -- VMs and just about any software in use should be backed up on a regular schedule.
Hardware elements, such as servers, switches, routers and other computing devices must be backed up as well. Most of these devices and their capabilities can be replicated in an alternate location -- e.g., cloud storage -- to ensure their rapid recovery if the physical devices have been damaged.
As noted earlier, the starting point in a policy specifies creation of a full backup and/or images of all relevant software-based systems. A full data backup consists of taking a complete copy of all the data on a particular host or set of hosts. If a data loss event occurs, the more recent the full backup is, the easier it will be to recover information. For this reason, some IT departments might run full nightly backups. In some larger environments, however, full backups might take more than 24 hours to complete and will consume a lot of tape resources -- if tape is used. In practice, data centers typically run full backups over a weekend and then run weekly incremental or differential backups to reduce both the nightly backup window and economize on tape media. Of course, today's high-speed backup protocols and high-capacity storage technologies can easily shrink the window needed for full backups.
Incremental backups only back up the data that has changed since the last backup job. For example, a Monday incremental backup following a Sunday full backup will only back up the data that has changed since the Sunday full backup was completed. Likewise, Tuesday's incremental backup will only back up the data that changed since completion of Monday's incremental. If a full system, tape-based data recovery had to be performed on Thursday, it would require loading the Sunday full backup tape(s), along with all the incremental backups from Monday through Wednesday, to obtain the most recent version of the information.
A good practice is to use separate, unique tapes for each nightly incremental backup job. This ensures some measure of local redundancy if a tape media cartridge happens to be defective or is broken in transport.
Differential backups, by contrast, back up all the data that has changed since the last full backup. For example, Wednesday night's differential backup would back up all the data that changed on Monday, Tuesday and Wednesday. In the same above recovery scenario, the Sunday full backup tape(s), along with the Wednesday differential backup tape set(s), is all that would be required to begin recovering the data.
Note: References to tape backup also apply to non-tape media, such as high-speed disk, RAID technology, NAS or solid-state disks.
Pros and cons
1. Backup types
Pros and cons can be identified for each backup approach. Incremental backups can be completed fairly quickly and only consume a small amount of backup space compared to either full or differential backups. This helps reduce backup windows and cuts down on disk or tape consumption. By contrast, if backups use tape exclusively, in a recovery situation, the process is more complicated and time-consuming, because more tapes must be loaded and scanned to process the recovery. The cons associated with tape backup and noted here can be mitigated with the use of high-speed disk, whose costs have been steadily declining over the years, making them very price-competitive with tape. Archival storage applications are typically very cost-effective using tape.
As described above, differential backups remove some of the recovery burdens that can occur when restoring from an incremental backup. However, if the application environment is often subject to daily data changes, the backup window could become elongated. In addition, differentials will consume more backup resources, because each differential backup copy moves and stores all the changed data since the prior full backup.
Integrating disk into a backup architecture is an ideal way to remove some of the complexities from the backup-and-restore process, especially if data deduplication -- dedupe -- is embedded on the backup disk array.
In this instance, there is no practical reason not to designate weekly full and daily incremental backups in a policy. For example, when restoring data from incremental backups saved on disk, it eliminates the need to swap multiple tape cartridges to process the recovery.
Types of data loss
Any event that damages or corrupts data can be considered a serious event, unless the data is perhaps archival and not likely to be regularly used. Data backup policies should specify data loss situations to be mitigated by backups, although this issue might also be included in a data management policy. If the data is stored on tape, destruction of the tape, magnetic interference wiping out the data, vandalism, theft and malicious code embedded on the tape are all situations that can cause data loss.
For tape stored on high-speed drives, similar situations -- e.g., physical damage to the disk drive and read/write heads, magnetic interference and the items noted above -- can damage or destroy data. A single backup policy should clearly specify all the potential data loss scenarios of concern to IT management and their remedies.
An appropriate backup policy backs up data to disk first and then moves data off to tape as it ages. Purpose-built deduplicating disk appliances are ideal disk backup targets because they can be used with several different backup applications. For example, some appliances support traditional backup applications, as well as Oracle Recovery Manager. Most deduplicating backup appliances also support tape-out processes.
Most deduplication appliances can efficiently store more than 30 days of backup data on disk, ensuring that end users can perform most recoveries directly from disk. Data that must be stored for long-term compliance -- e.g., legal, regulatory -- purposes can then be gradually moved off to tape.
Craft a reliable backup policy
The purpose of backup policies is to ensure that there is a consistent and reliable method for recovering data. Ad hoc backup policies such as providing a network file share for end users to copy their data can be a potentially risky proposition. Therefore, good practice states that IT should take ownership of backing up all data. Otherwise, it's possible that critical business data might be lost at some point in time and, regrettably, IT will be held accountable.
Regularly scheduled backups and well-defined, clearly documented data backup policies bring more predictability to the recovery process so that administrators and their successors will know where data is stored for recovery and the procedures for restoring that data.
Regardless of the backup architecture deployed, establishing structured and well-defined data backup policies is essential for ensuring the consistent protection of business data.
An organization should consider the following issues when developing data backup policies:
- technologies used for backing up, recovering and restoring data and systems;
- types of data and systems to be backed up;
- network infrastructure requirements to ensure backups can be completed;
- professional staff charged with performing backups and recoveries;
- emergency procedures if data backups become compromised; and
- procedures for ensuring that critical data is securely stored in the event of a data breach, ransomware attack or other cybersecurity event.
In creating data backup policies, first begin by capturing the above data; it serves as the starting point. Next, consider the following preliminary activities:
- Examine current IT and other company policies for policy structure and format and use relevant components for the new policy.
- Research the internet for examples of data backup and recovery policies and adapt them as appropriate.
- Examine software products that can assist in preparing policies.
Components of a data backup and recovery policy
A data backup and recovery policy can be simple. A few paragraphs can be enough for backup and recovery activities, noting the metrics -- e.g., RPO -- discussed previously. Include more granularity, if necessary. Following is a basic policy outline that can be formatted to address backup and recovery issues:
- Introduction. States the fundamental reasons for having a data backup and recovery policy.
- Purpose and scope. Provides details on the policy's purpose and scope.
- Statement of policy. States the policy in clear, specific terms.
- Policy leadership. Identifies who is responsible for approving and implementing the policy, as well as issuing penalties for noncompliance.
- Verification of policy compliance. Describes what's needed, such as gap assessments, audits, performance data and exercise results, to verify that data backup and recovery activities comply with this policy and any other IT policies.
- Penalties for noncompliance. Defines penalties for failure to comply with policies.
- Appendices (as needed). Incorporates added reference data, such as lists of contacts and service-level agreements.
Upon completion of a draft data backup policy, have it reviewed by IT department management, human resources and legal, at a minimum. If time is available, invite other relevant departments to comment.