Actually, far in advance of any of the stuff you've mentioned, a BCP (Business Continuity Plan) is necessary. Basics include identifying disaster scenarios and what triggers they have, determining what parts of the business are the most important to have back up and running quickly (and I'm not talking about tech here; it's business units); which ones need to be back up in 24/48/72/240 hrs, where will the business go if the location is destroyed, which employees will still need to work, how they will communicate, etc. There are a lot more. My experience has been that this is one of the tougher things to nail down; most businesses larger than 50 employees don't have a clue about this stuff. Once you get everyone together on it, nail down all those parameters, and get management signoff on it, then you can start dealing with what data/applications/infrastructure need attention. The plans I've done in the past focus on tiered recovery; getting the critical stuff available first and adding to it as time goes on. I've also found that most businesses are stunned by the costs involved in recovering their businesses even with long time frames. Thorough planning and documentation, starting with the business architecture, is critical to selling management on even the most basic DR plan. As you gather data, the matrix required for the different scenarios becomes quite complex indeed...
The reality for many businesses becomes exactly what the Dilbert cartoon shows... *********************** Charlie Kaiser [email protected] Kingman, AZ *********************** > -----Original Message----- > From: Ben Scott [mailto:[email protected]] > Sent: Thursday, June 24, 2010 9:10 AM > To: NT System Admin Issues > Subject: Re: DR Plan > > On Thu, Jun 24, 2010 at 11:22 AM, Jay Dale <[email protected]> wrote: > > I've been assigned to create a DR plan for our company ... > > http://i.zdnet.com/blogs/dilbert_disaster_recovery_plan.jpg > > > I've never actually had to come up with one before. > > There's two major parts, the analysis/cost planning part, > and the technical/procedural planning part. > > The basics of analysis are: > > A1. Identify resources > A2. Obtain figures for what non-availability of each resource > costs A3. Identify threats to resources (such as disk > failure, building fire, etc.) A4. Identify possible > counter-measures for each threat, and costs of same A5. > Compare cost of downtime with cost of counter-measures, > taking into account the likelihood of each threat. This > tells you what counter-measures are worth it to your situation. > > Planning the technical/procedural is also conceptually simple: > > B1. Figure out how to do what you decided on in A5 (read the > manual, etc.) B2. Write everything from B1 down B3. Test > everything in B2 B4. Take what you learned in B3 and apply it > to B2; repeat B2 and B2 as needed B5. Once you've got a good > plan, practice it periodically B6. Keep an eye on everything > and repeat all steps as needed > > The devil is in the details, as usual. Entire shelves > worth of books have been written on the subject. > > -- Ben > > ~ Finally, powerful endpoint security that ISN'T a resource > hog! ~ ~ > <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
