Backups are often run at different levels on different days, with ‘full’ backups containing all of the data required for a restore and ‘incremental’ backups relying on data from the previous full and subsequent incrementals for a restore. Incremental backups are popular due to the decreased time taken to complete and lower storage requirements. However, there is a subsequent cost on the recovery side as the time and number of tapes required to carry out a full restore increases with each incremental, as does the risk of a bad tape preventing a complete restore.
A policy covering backup levels needs to be put in place within the DPM product that provides details of either how often a full backup should run or of the maximum number of incremental backups can between two full backups. A policy on the maximum number of tapes required for a restore or the length of time between full backups should be put in place and enforced through automated checks.
Backups Must Cover The Entire Application
Backup systems work at the level of the filesystem or server rather than at the level of the application or business unit. An application that can be described in business terms as “the customer web portal”, for example, may actually consist of multiple servers, databases, filesystems, etc. that have no inherent relationship. Unless all of the pieces of each application have been backed up there is a risk that it cannot be restored if needed.
It is important that the DPM product is able to display a consolidated application-level view of data protection. The restore point for the application is going to be further back in time than the last successful backup of any part of the application, but how much further back? If there is a site failure then from when will you be able to obtain a restore of the entire application? Equally important, how long will such a restore take? Due to the often manual nature of restores it is hard to get a highly accurate answer to the latter question, but a good estimate is a very useful number to have.
Backups Must Be Set To Expire At The Right Time
Each backup that takes place has a built-in expiry date. Beyond this expiry date the details of the backup will be forgotten, and the data itself will often become unavailable. With the advent of legislation that requires data to be available for significant periods of time, commonly up to 10 years, expiry periods for data need to be set to retain the backed up data for the appropriate length of time. Equally important, when the expiry time for the backup has been reached the tape on which the backup resides should either be destroyed or recycled.
Businesses need to have a clear data expiration policy, based on both internal and external requirements and defined separately for different categories and types of data as required. Backups need to be classified against these categories and types, and checks must be made at the point of backup to ensure that expiry dates are set correctly. Checks also need to be made to ensure that any tapes containing expired backups are either destroyed or recycled.
A backup that is considered successful by the backup application can no longer be said to be truly successful unless a number of extra criteria are met. The question of “Is my business protected?” cannot be answered by backup applications alone. Advanced Data Protection Management software is required to bridge the gap between the technical and business definitions of success. Each business, and often each department within the business, may have different success criteria depending on the internal and external regulations to which they are party, and reporting needs to be flexible enough to allow for this. Finally, backup reporting needs to be provided in a way to which the business can relate; reporting on applications and business units rather than servers, databases and filesystems.