After determining why the data needs to be backed up and the recovery requirements, you are ready to look at how your particular business requirements come into play. You need to determine how often each type of data or each system needs to be backed up, what the restore requirements are, what the data retention policy needs to be, any security requirements, off-site storage requirements, and unique business unit requirements. All of these items must be addressed.
Developing a Backup Strategy
To start this phase of architecting your backup and recovery strategy, you need to look at the frequency of backups and the required retention of the data. This is usually controlled by the business, legal, and recovery requirements. The business requirements that generally affect the backup strategy are those that define how long specific types of data must be kept available either locally or in a storage facility. These requirements could also specify the number of copies of the data that must be retained. In some cases, there are specific business requirements regarding how often specific data is backed up. Legal requirements must also be considered, although they are usually the basis of the specific business requirements. When you are dealing with data that might fall under control of any of the many governmental regulatory agencies, you must make sure your strategy complies with all their requirements.
Business Requirements
The specific business requirements that you need to consider include the following :
-
Service-level agreements to business units. What backup and recovery guarantees do you have?
-
Unique requirements for specific data. For example, all original circuit design must be kept for seven years.
-
Recovery time objectives. How fast will specific systems/applications be recovered?
-
Recovery point objectives. How far back in time are you willing to go to recover?
Legal Requirements
The legal requirements you need to consider are generally those imposed by governmental regulatory agencies. These typically involve specific data retention requirements for specific kinds of data. What makes this even more challenging is that these requirements can change because of changes in administrations or new laws. These can also dictate how many copies of the data must be kept and where it must be kept.
Recovery Requirements
As you build your strategy, you should make a special note of systems or applications that have special recovery requirements. These are usually covered by the business requirements but are worth mentioning again. We have found it much better to always look first at the recovery requirements when building a backup strategy, since that is probably the reason you are doing backups.
With these absolutes in mind, the next step is to take the information gathered in the first chapter and start your backup matrix. As you put this together, you should also consider the type of backup you need. Following are the different backup options:
-
Full backup. This backup copies all the files and directories that are below a specified directory or filesystem to a storage unit.
-
Cumulative incremental backup. Scheduled by the administrator on the master server, this option backs up files that have changed since the last successful full backup. All files are backed up if no prior backup has been done. This is very similar to a differential incremental backup, which is covered later, with one very major difference. In the event of a full system recovery, a cumulative incremental backup would require only two images: the last full backup and the most recent cumulative incremental. While this speeds the recovery process, this type of backup does require more tapes than the differential incremental and may potentially take more time, because you are backing up all the files that have changed since the last full backup.
-
Differential incremental backup. Scheduled by the administrator on the master server, this option backs up files that have changed since the last successful incremental or full backup. All files are backed up if no prior backup has been done. This is what most people traditionally refer to by incremental backup. During a full recovery, using this type of backup could require more tapes. However, do not base your architecture decisions just on these two definitions, but rather on the information gathered during your initial discovery phase.
-
True image restore. This type of backup restores the contents of a directory to what it was at the time of any scheduled full or incremental backup. Previously deleted files are ignored. You can also select Move Detection, which specifies that true image incremental backups include files that were moved, renamed, or newly installed.
 |
The example the data that is included in a series of backups between January 1 and January 4. The January 1 full backup includes all files and directories in the policy file list. Each of the cumulative incremental backups include the data changed since the last full backup. If the disk fails sometime on January 4 (after the backup), the full and the last cumulative incremental are required for the recovery.
For this example: Recovery = Jan 1 (full) + Jan 4 (incr)
|
|
The example shows the data that is included in a series of backups between January 1 and January 4. The January 1 backup is a full backup and includes all files and directories in the policy file list. The subsequent backups are differential incrementals and include only the data that changed since the last full or differential incremental backup. If the disk fails sometime on January 4 (after the backup), the full and all three of the incrementals are required for the recovery.
For this example:
Recovery = Jan 1 (full) + Jan 2 (incr) + Jan 3 (incr) + Jan 4 (incr)
|
|
The following are examples where using move detection backs up files that otherwise would not be backed up:
-
A file named /home/pub/doc is moved to /home/spec/doc. Here, the modification time is unchanged, but /home/spec/doc is new in the /home/spec/ directory and is backed up.
-
A directory named /etc/security/dev is renamed as/etc/security/devices. Here, the modification time is unchanged, but/etc/security/devices is a new directory and is backed up.
-
A file named /home/pub/doc is installed by extracting it from a UNIX TAR file. Here, the modification time is before the time of the last backup, but the doc is new in the /home/pub/ directory and is backed up.
-
A file named docA is removed and then a file named docB is renamed as docA. Here, the new docA has the same name, but its inode number changed, so it is backed up.
NetBackup starts collecting information required for move detection beginning with the next full or incremental backup for the policy. This first backup after setting the attribute always backs up all files, even if it is an incremental.
Move detection takes space on the client and can fail if there is not enough disk space available.
|
|
The following table shows the files backed up in the /home/abc/doc/ directory during a series of backups between 12/01/2001 and 12/04/2001. Assume that True Image Restore Information was selected for the policy that did the backups.
FILES BACKED UP IN THE HOME/ABC/DOC/ DIRECTORY[*]
| DAY | TYPE OF BACKUP | FILES BACKED UP IN /HOME/ABC/DOC | ||||||
|---|---|---|---|---|---|---|---|---|
| 12/01/2001 | Full | file 1 | file2 | dirA/fileA | dirB/fileB | file3 | ||
| 12/02/2001 | Incremental | file1 | file2 | dirA/fileA | ----- | ---- | ||
| 12/03/2001 | Incremental | file1 | file2 | dirA/fileA | ----- | ---- | ||
| 12/04/2001 | Use backup | file1 | file2 | dirA/fileA | ----- | ---- | dirC/fileC | file4 |
| 12/04/2001 | Incremental | file1 | file2 | ---- | ----- | ---- | ---- | file4 |
| Note: Dashes indicate that the file was deleted prior to this backup |
Also, assume that you are going to restore the 12/04/2001 version of the /home/abc/doc/ directory.
-
If you do a regular restore, the restored directory has all files and directories that ever existed in /home/abc/doc/ from 12/01/2001 (last full backup) through 12/04/2001:
file1
file2
dirA/fileA
dirB/fileB
file3
dirC/fileC
file4
-
If you do a true image restore of the 12/04/2001 backup, the restored directory has only the files and directories that existed at the time of the incremental backup on 12/04/2001:
file1
file2
file4
NetBackup does not restore any of the files deleted prior to the 12/04/2001 incremental backup.
The restored directory does not include the dirA and dirC subdirectories, even though they were backed up on 12/04/2001 with a user backup. NetBackup did not restore these directories because they did not exist at the time of the incremental backup, which was the reference for the true image restore.
|
[*]From the NetBackup 4.5 DataCenter System Administrator's Guide, VERITAS
Frequency of Backups
Once you understand the general backup requirements for all of the data and the business and legal requirements, you should have a pretty good idea of how much data needs to be backed up and at least a minimum requirement for the frequency. The trick in establishing the ideal frequency policy is to come up with a schedule that gives you adequate protection with minimal media usage. You don't want to back up any more often than needed to get the necessary level of protection, since 'more often' means more tapes, more data being moved, and more administration. When in doubt, however, go with more media.
Establishing the best frequency and retention policy for data that is not covered by business and legal requirements also involves knowing why the data is being backed up and what recovery requirements are. In general, truly static data or static systems should not need very frequent backups. They might be backed up as infrequently as once a week or even once a month. As far as the number of copies required, a normal practice is to keep between two and four copies of the backups.
Data that is more dynamic requires more frequent backups and probably needs one of the incremental types. The decision between differential incremental and cumulative incremental is based on recovery requirements versus media usage. Weekly full backups and daily differential incremental backups could require up to six tapes to restore a directory, filesystem, or database in a worst-case scenario. Each of the incremental backup images might be small, but each day's changes could be on a separate tape, or at least different images on the same tape. If you did the same backup sequence with cumulative incremental backups, no recovery would take more than two images that could reside on two tapes; however, if there were enough changes to the data, the cumulative incremental backups could approach a full backup in size. You must decide whether it is better to use fewer tapes with differential backups but run the risk of having to mount more tapes on a restore or potentially use more tapes on the backups but only have to restore two images to restore an entire backup.
Obviously, another piece of this equation is the anticipated type of recovery activity. If the data is being backed up for DR protection or to protect against hardware failures, the question of differential versus cumulative is important. If the data is being backed up to protect against user deletion or error, you should stay with differential backups. The recovery requirement also comes into play. By using the information you gathered during the interview process with the data owners, you can realistically plan based on the expectations you set during your discovery. If the absolute speed of recovery is important, the use of cumulative incremental backups is desired. The incremental type generally comes into play when you are working with filesystem backups. With databases, you generally work with the application tools that are integrated with the backup application, and this will dictate much of what you do.
Retention of Backups
A very common mistake people make is to retain their backups for too long. This increases the cost of backups, since you will need more media. You need to make sure you understand all the legal and business requirements for keeping copies of the backups and ensure you meet them. For normal operations, you want to make sure you have a retention level that at least exceeds the frequency. If you do a particular backup weekly, the retention level must be at least one week or you will be unprotected. A general practice is to keep at least two cycles of each type of backup. This way you will always have two copies of the data on tape when doing the next backup. This method allows you to recover from a crash that might occur on the day/time for the next backup, plus it provides an extra copy in case there is a problem with one of the tapes. Another common practice is to assign off-site tapes a different retention level than tapes kept on-site. The reasons people do this vary, but in most cases, it is driven by the business. For instance, perhaps the business requires that the backup images be kept on-site for 30 days for recovery purposes, while off-site images must be kept for 180 days.
Give this entire issue some careful thought, and don't just say you are going to keep everything forever. If this describes your particular situation, you do have an uphill battle ahead of you, but it's not the end of the world. The best thing to do from this point on is to make sure you can classify your data properly, then redesign your backup policies so you are only backing up and keeping the data you need for the periods of time you require.
Security of Backups
Security of the backups is something else that must be taken into consideration. Your business might require encrypted backups so that the data on the tapes cannot be recovered without the proper key or password. Many backup and recovery applications offer this kind of backup, but there is a performance penalty associated with encrypted backups. The data will be encrypted on the client system before being sent across the network, so this will require CPU cycles on the client and will also slow down the rate of data being presented to the network for backup. The data is very secure, since it is encrypted before it is sent across the network and is still encrypted when written to tape. This also requires the key be known in order to do a restore. Most people rely on keeping the media secure rather than implementing data security by using encryption.
Off-Site Storage Requirements
Most people today realize the need to implement a true data protection strategy of which backup is an integral part. One of the components of this strategy is management of off-site media. You should always select a backup product such as VERITAS NetBackup that offers an automated vaulting or off-site storage solution so you have the management tools for tracking the media that is off-site. The questions that you are addressing for an off-site or vault solution are as follows:
-
What images need to be sent off-site?
-
How many copies of the images need to be kept off-site?
-
How long should each image or type of image be kept off-site?
-
Do we have enough tape media on hand to allow for two or more copies?
You must determine which systems need to have off-site copies of their data and if all or only part of that system needs to be sent off-site. Sending a backup tape of the operating system off-site is typically not necessary and not cost-effective. You will need to know if incremental backup images as well as full backups are required for off-site. This requirement can be different for each type or class of system. It also depends on the existence of a DR site and legal requirements.
How Many Copies?
The next question is how many copies of each backup image should be kept off-site. This usually depends on why the data is being stored off-site. If there are legal requirements, then these requirements usually stipulate how many copies. If it is being done for pure DR, one or two copies might be adequate. This decision is usually based on either specific legal and business requirements or on your overall DR strategy. In cases where an off-site storage facility is used, you might only need one copy. If there are multiple sites, it is common to send copies to a sister site that can act as a DR site. In these cases, you might want two off-site copies so one can be kept locally and the other at the remote site. What you really need to do is keep an open mind and take a look at all the possibilities and requirements.
How Long Should They Be Kept Off-Site?
If there are legal or business requirements, these must be met. A common legal requirement is that all data related to any financial trades must be retained for seven years. The other considerations are how many potentially different copies of an image do you want to store off-site and how many tape cartridges are you willing to maintain out of production? Again, it may be up to the business unit managers as to how long they want their data stored off-site. In most companies, the IT department views the business units as their customers; as such, there are costs involved in the services you are providing to your customers. Similarly, when the business unit manager requests that his or her data remain off-site for two years, you must present the costs associated with the management of this data. There will be the cartridge cost, pickup/delivery costs, and storage costs. Even if you are not charging this back to the managers, it is a good idea to document this for your management. Once you are able to present people with the facts, reality sets in and you are able to help them reasonably determine the proper length of time for off-site storage given their business requirements.
Differences between Business Units
Sometimes data must be segregated between business units. There are several ways to do this. The most secure way is to have multiple tape libraries and do the different business unit backups to different physical libraries. Sometimes this is not possible or practical. If this is the case, there are other ways to accomplish this. With a tool such as VERITAS Software's NetBackup, you can establish unique volume pools and assign media to a specific volume pool. You then assign specific backups to specific volume pools. This allows you to logically segregate the data within a single tape library. We discuss this in more detail later when we look at installing and configuring a backup product. One word of caution: Just because your software solution supports it doesn't mean you have to implement it. In other words, if you do not have a compelling reason to implement multiple volume pools, then by all means do not add a level of complexity to your environment simply because you can. Backup products like VERITAS NetBackup are quite scalable and easily modified should that be a requirement down the road.
Other differences between business units may potentially affect how you architect your backup strategy. Often these will result in unique backup and recovery requirements for some systems. With most backup products, you can set up backup policies for similar clients with similar requirements and separate the clients that have unique needs. You must always be aware of any of these unique requirements before putting your strategy together.
|
Thus far, we have discussed architecting a backup and recovery system. Most of the points I have addressed are based on my experiences helping enterprise users put together their systems. I would like to share my experiences with one such organization that I visited. This was at the height of the e-business explosion. The company was just getting started and was planning to go global. They were starting with a data center on the East Coast, then another on the West Coast, to be followed closely by one in England. I went to their main office with the local sales team to help evaluate their recovery needs and to see if we would be able to help them achieve their objectives.
When we arrived for the first meeting, it was obvious they were very concerned. After brief introductions, they launched into a description of their environment with interjected comments about their situation being just about hopeless. One of the first statements was 'You have no idea how much data we already have, and we are just getting started. With our projected growth, I don't see how we can possibly back up all our data.' They went on to list all of the existing servers with the amount of storage on each and a grand total. They also summarized their network configuration, the backup-related hardware they had already purchased, and last but not least, their growth projections. The amount of data was impressive. After looking over all this information, my first question caught everyone by surprise: 'Why are you backing up this data?'
'Why? Why, we have to. One of our competitors just experienced some type of outage and did not have proper backups. It was a total disaster for them. What do you mean, why?'
I had to rephrase my question so they could understand what I actually was looking for: 'How many of your systems have active users with volatile data that might result in files being regularly restored because someone deleted a file or wanted to revert to an older version?' After a few minutes of discussion, they decided this would probably only involve a small number of their total systems. 'How many of your systems are you backing up just to protect against hardware failure or some type of system crash? How many of your systems are pretty static as far as the data? How many of your systems are running a critical application that you want to ensure are protected from system crashes, hardware failures, and application errors?' We discussed all the different things they wanted to protect the different systems from, and they started to build a different list. By using common sense and actually looking at each system, they were able to determine that their backup challenge was not as bad as they originally thought. They even discovered that a lot of their interface systems were really just replicated systems, so they only needed one copy of the data, not 50.
In subsequent meetings we started to look at their planned environment in more detail and were able to make suggestions in all areas of their backup and recovery strategy. What we were really doing was getting them to look at the backup strategy from the other end, the recovery requirements. You will always be more successful if you approach it this way.
No comments:
Post a Comment