A note on HA/DR solutions, and one that's not always considered, so bear with me. Yes, I'm playing Devil's Advocate.

The most likely need for HA/DR is power outage and/or fire in the building. Let's exclude statewide catastrophes or invasions from Mars.

If your building has no power (think line cut by a backhoe right outside), do your employees need to work? Do you have VPN capabilities for the majority, if not all, of your staff to login to the apps they'd need to do their jobs? If not, then those don't need HA/DR, they just need to make sure your backups get offsite in case of fire.

Do your customers come to you online and do the majority of their purchasing/sales/etc without any human interaction? If so, then you need to setup your HA/DR so that the DNS at your IP knows to switch over in case of failure or you need a plan.

There's a TON of things to be concerned about with HA/DR, and it's not just 'is my data protected', though that's a nice to have secondary output of proper setup. Disaster Recovery is different than High Availability, and combining the two is an animal in it's own right that you need to be sure you're wisely using resources and time to construct for something that you could actually use.

I know many companies that if the building burns down... it doesn't matter what the hell happened to the data as long as the accounting database is backed up somewhere to answer creditors. That company is GONE. Just gone. They can't recover from the loss of product in the warehouse, machinery on the floor, etc. Part of the process is determining what disasters they're actually feasible to recover from.

Example: Your VPN goes through Site A, which has a T1 connecting to Site B where you have all your servers, apps, etc. Your HADR is at Site C... which only has a connection to Site B. Guess what... it's worthless. Your VPN can't get to Site C. I was recently staring at this setup so I can't go into more details, NDAs, but it illustrates the ten thousand things you need to think about for setting this up.