Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Paranoid and Proud of It: Planning Your Backups-2 : Page 2


advertisement
Questions That Need Answering
As always, whenever you create a backup plan, there is a tradeoff between cost and effectiveness. A backup plan that utilizes drives from EMC mirrored over a fiber optic network will be more effective than a nightly backup to tape, but it will also cost more. Before you drill down to actual solutions, it is important to establish the parameters for your decisions. Here are the questions that you will need to answer.
  • What, if any, downtime is acceptable? What does downtime cost? The answer to these questions vary widely, based on your business and your system. For example, if you run a human resource system that is used for reporting purposes, the acceptable downtime will be a lot greater than one for an e-commerce site taking orders 24 hours a day. Depending on the nature of the system, there may also be portions of the day or business cycle where uptime is more important. For example, it may be OK to take the payroll system down for several hours during the week. But downtime will have much more impact if it is on the day that payroll is supposed to be distributed. Analyze the workload of the system to determine if your uptime needs vary. This will also allow you to schedule any preventive maintenance and downtime better—if it does need to occur.

    Make sure to get answers to these questions in hard numbers. Answers such as "uptime is very important"—while perhaps true—will not help you plan. The actual numeric answers can come in different flavors. It may simply be a percentage such as "we need to be up 99.9999 percent of the time" ("six sigma" as it's called in the industry). You could also obtain a measure of the number of incidents that can occur. In some cases, a one-time incident where the system is down for six hours is more manageable than several instances where you're down for five minutes at a stretch, even if the total downtime is less than six hours. You also need to determine the cost of any downtime in actual dollars. This will allow you to evaluate the cost of your backup solution in terms of the dollars saved by preventing that downtime. In some cases, the answers you receive may mean that you are not justified in obtaining that fancy hardware and backup solution you've had your eyes on. In other instances, it will give you the necessary ammunition to justify your case.

  • How fast does the recovery process need to be in case a crash does occur? This question is closely related to the amount of uptime you need to provide, but should still be explored separately. The answer may not be a one-size-fits-all solution but may depend on the type of crash you experience. For example, in case of an earthquake or explosion, both the business and your customers may understand and be willing to wait several days until they can access the system. However, for something as "simple" as a disk crash, you may be expected to be back up within ten minutes. Of course, in some cases, such as a company that needs 99.9999 percent uptime, you may receive the mandate to ensure that recovery is almost instantaneous, regardless of the situation.
  • What, if any, data loss is acceptable? Just as uptime is important, you also need to examine what the implications are if any of the information in your system is lost due to a system crash or other human failure. The less you can afford to lose, the more rigorous (and potentially more costly) your plan will be. Depending on the use of your system, your answers will vary widely. If your system supports huge fund transfers to and from the Federal Reserve Bank, you probably can't afford to even lose one transaction. However, in other cases, there may exist a paper trail that the business will be able to use to recapture activity for some period of time. Or the business may make a conscious decision to accept some data loss willingly. For example, one telecommunications company I used to work for made a strategic decision that if a system crash occurred, it was more important to keep the calls going through than to worry about billing for the calls. Therefore, they built into their system a way to bypass authentication and recording of the calls (done through SQL Server) if necessary. They willingly lost data in order to keep their customers happy.


  • Whom should you ask these questions? Make no mistake: if a severe problem occurs that affects your business, your every action will be scrutinized. Therefore, ensure that the people who have the actual authority to make decisions answer the questions above. It is best if the people from the business side are involved in the decision process, not that it's left up to someone in the IT department alone to resolve them. Of course, once decisions have been made, make sure to document them in your plan. This is not simply to cover you, but to also provide a basis for understanding the plan and reevaluating it when changes occur to your business.


Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date