How tight is your DR

Your business is growing but who is keeping the lights on ?

Do you run regular DR Tests ? 

Do these tests actually swap Production and run it from the DR site, run BAU operations, then switch back to Prod ? Do all the data changes whilst in DR get sync’ed back to Prod?

If the answer is yes, that’s great and please let us know as we could use your on our team 🙂 If not, it is not as difficult as it sounds to get this in place. Here are the key considerations:

1. Align the solution to business requirements (such as Recovery Time Objective (RTO) and Recovery Point Objective (RPO). If you have a network and SAN at the DR data centre this will not be too hard. Also, consider RTO as an RTO of 4 hours (common for even some of our most critical apps) will allow simple, cost-effective failover solutions to be employed whereas an RTO of less than an hour will likely require a lot more money and technology.

2. Build the IT infrastructure at the DR site that can handle Prod workload. This does not necessarily have to be a 1-for-1 with Prod (e.g. High Availability (HA) that is built for Prod may not be required for DR)

3. Ensure all connecting systems to Prod are able to also connect to DR (e.g. apply the same firewall rules in Prod to DR then run telnet tests to check, change apps connection strings to use dns rather than a hostname or an IP address. Even better if you can do it via a Load Balancer). Test this in Non-Prod.

4. Where there are databases, use a DB replication tool such as SQL Always On or Oracle Dataguard as this will allow a < 1 hour RTO if managed correctly. As this is where the data lives, data remains sacrosanct at all times during a failover and a failback.

5. Construct the runbook, review several times with the team and run a DR test

Click here for a Whitepaper that explores this in detail