GSquared (3/8/2011)

---

To a very large extent, DR planning will depend on specific business needs, hardware availability, skillset availability, resources available/obtainable, and SLAs/SLRs.

Virtual machines can be part of a DR plan, but more often, they're part of a money-saving plan. They can help if a motherboard crashes, but they aren't really part of handling database corruption, I/O failure, power outages, facility damage/destruction, data loss due to developer/DBA incompetence/accident, et al.

I seriously recommend hiring a contractor who specializes in disaster prep and recovery and going over business needs, etc., with that person. It'll take some time and some (a lot of) work, but you'll end up with a better plan, more suited to your specific needs, than you will by asking a few questions on an online forum and getting a few short, generic answers.

If you can't go that route, then start with the basics. Tested backups, some sort of co-location in case of fire/earthquake/hurricane/civil unrest/etc., redundant power sources (tested, checked, fueled regularly), multi-channel SAN with appropriate RAID arrangements, logs on different I/O systems than data files, server redundancy (mirroring, log shipping, replication, clustering, VM, or some combination thereof), spare hardware (hot-swap drives and spare power supplies at the very least), and, most important, a plan that has been drilled and tested to see how long it takes to recover from various levels of server/database issue.

Those are all general. Hiring an expert will get you specifics applicable to your situation and your business, your budget and your geography, etc.

GSquared (3/8/2011)

---

I seriously recommend hiring a contractor who specializes in disaster prep and recovery and going over business needs, etc., with that person. It'll take some time and some (a lot of) work, but you'll end up with a better plan, more suited to your specific needs, than you will by asking a few questions on an online forum and getting a few short, generic answers.

Manvendra (3/8/2011)

---

Ok suppose i have to ceate a DR solution for a instance whihc has more than 100 dbs and b sizes is approx upto 30-40 gb.cost is not a constraint for this.Can u pls advise the better solution.Ideally we can go with Logshipping only because mirroing is not possible here......but dont u think its very complex to manage tht logshipping setup?so in tht case wht sud we do for DR? and also whts is proc and cons of Vm boes in tersm of sql server?

GSquared (3/9/2011)

---

How transactional are the databases? Does it vary from database to database or are they all the same? What kind of connection are you log shipping through and how much bandwidth does it have? How fast does your co-location restore the shipped logs and how reliable is their uptime? How reliable is your uptime? Are you backing up to a separate I/O subsystem than your data and log files? Are your databases on a SAN? If so, how is that configured? How about your log files? The backups?

alen teplitsky (3/9/2011)

---

the pro's of vmware is that you ship the entire instance to DR and just mount it on your DR vmware host and change the IP. no need to mess with logins or anything else. assuming you have dynamic DNS everything should work in 15-30 minutes since the instance is just a bunch of bits on your network that can be moved between any vmware server