Planning a Backup Strategy
White Paper
Backups, restores, and data recovery operations are some of the most important tasks that
an IT organization performs. Businesses cannot risk losing access to data for any significant
amount of time; therefore, the organization should develop and follow a detailed plan,
commonly called a backup strategy. An all-encompassing, master backup strategy can be
difficult to apply consistently due to differences in staffing and technologies that typically
exist from one business unit to another throughout an organization. It may be valuable to
develop individual strategies for various business units or user groups, depending on
application usage.
The process steps described in this section are iterative. Each step can be performed with
variations, whenever a new customer’s service level agreement (SLA) impacts backup,
restore, or data recovery requirements; or if business needs change and affect the
previously mentioned.
Note: executing the final steps of the backup strategy described below involves the implementation and testing of the storage solution selected. For additional details about piloting, testing, and releasing new technologies into the production IT environment, see the MOF release management guide.
An understanding of the following concepts is important when developing a backup strategy:
What is Backup?
A backup is the process of periodically moving data from one type of medium (typically hard disk) to a secondary storage medium for potential retrieval at a later date (short-term, usually within a few days to a couple of months). The secondary storage medium is most often magnetic tape, but may also include hard disk, CD-ROM, and optical disk. Write specific policies to inform users of their responsibilities regarding backups. For example, personal data is typically the responsibility of individual users to store and restore. Company data is often stored on servers that are subject to scheduled backups, thereby ensuring data restore and recovery capabilities. Write procedures that explain these policies to users along with the defined backup schedules for different classes of data.
What is Archival Storage?
Archival storage is sometimes referred to as “data archiving,” is essentially the same task as a backup, except that the intent is to store the data for long periods of time, possibly forever. Often, data must be kept for long periods of time because of legal reasons, and it is important that these reasons be known to the storage manager and taken into account when planning for storage needs.
What is a Restore?
responsibilities with regard to data restores. For example, personal data is typically the responsibility of individual end users to store and restore. Company data, on the other hand, often has to be stored on servers that are subject to scheduled backups, thereby ensuring data restore and recovery capabilities, should the need arise.
What is a data Recovery?
Data recovery is the process of completely restoring data to the state it was in at some prior point in time. Data recovery is usually performed as a result of some kind of disaster that has caused serious data loss, corruption, or both. Although we often think of disasters as being either natural (as in the case of an earthquake) or man-made (as in the case of a computer virus), a disaster can be defined as any event that causes serious interruption to the running of a business. For example, a hard disk crash on a production system could cause an e-commerce system to cease operation, and for many companies, would qualify as a disaster requiring a complete data recovery. Proper planning could mitigate these circumstances
Classify Data
One of the first steps that operations must execute prior to developing a good backup strategy is to classify the various types of data in the IT environment. For example, most organizations do not back up “user data,” defined as personal data not related to the business. So, “user data” would be a type of data classification that could be ruled out of scope for scheduled backups and therefore falls to the responsibility of individual users to store.
“Company business data,” on the other hand, could be a classification of data that is important to the
company and is scheduled for regular backups. Within the “company business data” classification, there could be varying levels of company data, such as “company private,” while other data types could be “company resource data,” “project data,” and so on.
A good rule is to classify data according to its business impact. For example, there is some data that the company must have available or the business cannot run—like a parts list for a manufacturing company. This type of data has a high business impact and should be classified accordingly. Sometimes there is data that does not have to be online all the time, but must be available when needed—for example, the testing data
generated by medical companies performing drug research. This too could be classified as “high business impact,” because the company would be at risk if a product was flawed, and the company could not produce testing data for the last several years.
Define Backup Requirements
When the different data types have been classified, the requirements and specifications for each data type can be defined. Note: Many of the specific requirements discussed here for determining a productive backup strategy should be provided to IT as the result of SLA development and not demand much time or effort for IT staff to discover. The service level manager and the customer liaison work with customer management to ensure the customer’s business requirements are satisfactorily addressed through the delivery of IT services. These requirements should include backup, restore, and recovery business needs, which are then negotiated and eventually committed to by IT. Each of these requirements is discussed in this section to ensure that nothing is missed during backup strategy development.
Determine how much data to store
Determine where the Data is located
Now that the types of data in the environment and the storage needs of each data type are known, one must determine where the data is located. This information is critical in determining the technologies needed to implement the backup strategy. For example, in a geographically distributed environment, with servers located across the country —or the planet—a centralized backup solution could result in flooding the networks with backup data. This could have a potentially serious impact on business productivity. In such a case, a localized backup solution may need to be considered, perhaps in an automated mode to reduce cost. Many companies are finding that a lot of valuable company business data is located on mobile personal computers. This can be a difficult situation for IT because attempts to back up desktop computers en masse are usually cost prohibitive. When more and more of these client personal computers are mobile laptop computers, the situation grows more complex. A recommended best practice is to direct all personal computer users to store company business data on targeted servers, which are backed up regularly.
Note: Fortunately, technologies are becoming increasingly available that allow users’ data and settings to
“follow” them whenever they move from location to location, thereby increasing productivity. Taking advantage of such capabilities should be a high priority for more IT organizations.
Determine Projected Data Growth
Another critical piece of information needed to develop a backup strategy is estimating the projected growth of data by type. IT should make sure that the backup strategy developed is not quickly outdated. Future plans about the projected number of users and what type of data they create should be considered. If the company is planning to hire 100 new employees, the amount of user and business data will grow accordingly. Prepare for the future and build in the required capacity.
Determine Backup and Restore Performance Requirements
Information Technology (IT) Operations needs to determine the performance requirements for backups, restores and recovery. These requirements should align with business needs. During the course of developing SLAs, specific service level objectives (metrics) regarding backup, restore and recovery performance are defined, negotiated, and agreed to between the different business units and IT. Note that these service level objectives must be monitored for compliance with SLAs to ensure that both IT and customer commitments are being met.
Determine the Database Backup and Restore Needs
A company’s most pertinent, critical data resides in databases. Each database is different; be certain to take advantage of the tools offered by database vendors for backing up, restoring, and recovering data contained in their different databases.
Most of the major database vendors provide the ability to back up their databases online, without shutting the database down. They typically provide tools that can generate lists of files that need to be backed up and ensure that control files, archive logs, redo logs, and table spaces are backed up appropriately. Some tools even provide event-driven archival capabilities that automatically execute archiving data when a volume exceeds a predetermined capacity.
Determine Time Tables for Backups and Restores
Determine the allowable timeframe for performing a backup.
For instance, user files can be backed up any time users are not working on them, while some transactional databases may only have a few hours available for backup. Evaluate the amount of data needing backup, the existing infrastructure, and the technologies to use to estimate the time required for each backup. In the case of offline backups, all these factors can affect users’ access to data. For this reason, calculations for backup time requirements should be compared to specific business requirements. If the business demands that users have access to data 22 hours per day, a four-hour offline backup will not work; another solution would need to be found (for example, online backup, SAN, and so on).
The allowable timeframe for data recovery on a per data type basis must be known. For example, it might be perfectly acceptable to take two days to restore some user files, while company business data might have to be recovered in two hours. When determining allowable recovery time, remember that this includes a combination of the time needed to access the storage media plus the time required to actually restore the data to disk. The clearest example of this is when a full system recovery is required and media must be obtained from offsite storage. This information is used to determine the specific backup schedules enforced by operations.
Determine Data Archiving (Offsite Storage) Requirements
When developing the requirements for different data types, also plan—for each type—how the storage media, should be secured and maintained. For instance, high business impact data should backed up regularly, and periodically stored offsite. User data, if backed up at all, will not require offsite storage. Security restrictions for data both onsite and offsite will also have to be gauged. Again, the data classification can help determine the security needs.
Also determine the length of storage time per data type. For example, user files may need to be kept for only three weeks, while information about company employees may be need to be kept for five years. Consider the following types of data and information when planning for offsite storage:
A full backup of the entire system, done weekly Contents of the Definitive Software Library
Documents required to support an insurance claim, such as hardware and software inventory records, and copies of purchase orders or receipts for computer hardware and software
A copy of information required to reinstall and reconfigure network hardware
Identify the Constraints
As with any strategy development effort, be careful that the backup plan does not conflict with any existing, or proposed, standards or policies. Security policies may exist that dictate restrictions for data access (for
example, who can request restoration of certain files), offsite storage (for example, which data must be securely stored in a vault), and so on. The backup strategy should comply with these policies.
SLAs should contain specific service level objectives for different IT customers (for example, user groups) that detail things like allowable time to restore, onsite versus offsite storage, backup schedules, and so on. The backup strategy should enable these service level objectives to be achieved. If a conflict arises, the storage manager and the service level manager determine a solution or renegotiate the service level objectives. The specific infrastructure may also provide certain constraints on the backup strategy. Available network bandwidth, storage devices installed, cost, and other factors can limit the final strategy.
Define the Backup and Restore Policies
With all of the information gathered in the previous steps, the backup policies can now be defined and documented. Do not publish any policies that cannot be enforced. Implement the appropriate monitoring and measurements to ensure compliance.
About Global Micro
Leading organizations reduce costs by leveraging our investment in infrastructure with efficient, cost-effective and transformational solutions from Global Micro. Customers consistently redirect savings derived from our approach to projects of higher strategic and personal value.
Tel: 011.731.0600 Fax: 011.731.0601 Email: [email protected]
www.globalmicro.co.za
As a guideline, storage policies should be developed with the following considerations:
Relating the data classification scheme to backup schedules. For example, company business data can be backed up once a day, database transaction data can be backed up twice a day, and so on.
Pertinent constraints. For example, all requests to restore files can be submitted through a request for change (RFC).
How long data will be backed up. For example, the data for Application X can be stored for one year. How backups are scheduled. For example, to avoid network overload, the data for Business Unit A is not
backed up at the same time as the data for Business Unit B.
Storage resource management (SRM). For example, storage events can be reported nightly and kept for one week.
Security considerations. For example, all company proprietary data can be encrypted. Maintenance considerations. For example, storage media can be tested.
Disaster recovery considerations. For example, in the event of hard disk failure, all data stored up to the end of the previous business day must be recoverable. For another example, in the event of a disaster— as defined by the contingency plan—all data must be recoverable to the end of the previous business week. Note that this policy implies that offsite secure storage exists and is being used.
Analyze the Backup and Restore Requirements
Review all of the requirement information gathered and the constraints and policies identified, reduce any redundancies, and document the results. This document is used as a basis for executing the next step in the process.
Storage management efficiency can be increased for environments that need to manage storage devices in a distributed environment. Consolidating storage servers in a central location can achieve this objective. Storage management administration, monitoring storage resources, and overall network performance can be
