Summary

 < Day Day Up > 



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.

start sidebar
REAL-WORLD CUSTOMER CASE STUDY: PROBLEMS AND SOLUTIONS FOR ENTERPRISE BACKUP AT GLOBAL COMPANIES

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.

end sidebar



 < Day Day Up > 



Implementing Backup and Recovery(c) The Readiness Guide for the Enterprise
Implementing Backup and Recovery: The Readiness Guide for the Enterprise
ISBN: 0471227145
EAN: 2147483647
Year: 2005
Pages: 176

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net