Disaster recovery plans exist to ensure business continuity when the worst happens. They allow organisations and individuals caught up in life changing events such as natural disasters to focus 100% on protecting people from harm, without the distraction of worrying about data and IT systems. Recent events – both climate related such as the hurricanes in the US as well as manmade events such as ransomware attacks –  have brought disaster recovery to the top of mind, and organisations are looking to boost their preparedness. As they do this, they should also consider some of the useful ways that cloud-based disaster recovery solutions can contribute to everyday business operations – even before catastrophe strikes. 

We all know that geographic redundancy and replicating critical workloads can keep businesses up and running during catastrophic events, but there are many more everyday use cases for DRaaS (disaster recovery as a service) that can drive additional value from the investment. A key use case is maximising the value of the test environment created as part of the DRaaS provision. Every DR plan needs to be regularly tested to provide assurance that it is fit for purpose, but beyond readiness there are a few other key reasons why testing can be important for your business.

When delivering Zerto for cloud-based DR solutions for our customers, iland creates an environment on our Secure Cloud with preconfigured networks for both live and test failovers. The test environment is completely isolated, and can serve as a sandbox for all of your DR and out of band testing needs, all without any impact to production or replication. That isolated environment can be used in a number of ways:

Code development/quality assurance

These days, almost all organisations do some level of internal development. Many have also adopted agile development principles along the way. Unfortunately, not everyone has adopted Test-Driven Development (TDD), whereby you write tests before you write code. You simply refactor the code until the test passes. Boom, automatic quality assurance – in an ideal world, that is.

With this newfound agility, however, comes the temptation to release code a bit too prematurely. Why not test in an isolated environment? By performing a test failover of your development systems, you can begin to run those applications in a pseudo real-world environment. Often, it’s not until the services are live that you find errors. Debugging in this sandbox allows for your development team to clean up what otherwise might have gone undetected until launch. This practice will save you from having to issue patches down the line and will ultimately result in higher quality code releases that are less likely to have negative impacts on your employees or customers.

Application changes/patching

Speaking of patches, back to my «in a perfect world» comment: they’re going to happen. Knowing that’s the case, it makes perfect sense to test the patches, or any other code changes for that matter, in a secure environment. We’ve had a number of customers find this test environment conducive to finding issues and bugs much sooner.

Security/penetration testing: Overcoming the fear factor

Let’s face it, as fearful of security events as we all are at this point, many organisations are also nervous of impacting critical systems by performing security checks on their production systems. Having an isolated environment to conduct security tests is invaluable.

Within this isolated test environment, you’re able to perform test failovers of the workloads you’d like to audit without impacting production. Now that you have a test bed established, you can start by performing penetration tests. There might be unknown critical vulnerabilities present on those systems, but you’ll be able to run a vulnerability scan, identifying chinks in your systems’ armour.

Following that, you could inject sample malware into the environment to put the system’s detection capabilities to the test. Other tools worth checking would be malicious file detection, intrusion detection and prevention, and URL filtering. There are many open-source tools and publicly available utilities for simulating malicious activity. Many iland customers have found security vulnerabilities and weaknesses in their IT systems by deploying DR security testing in this way. In other words: “Hack” away my friends!

As you can see, I’ve identified a few, pretty cool, use-cases for DR testing that go beyond its primary purpose. While the occurrence of natural disasters may well be the prompt that starts organisations looking more closely at cloud-based disaster recovery, once they do I think they’ll find some seriously compelling reasons to build regular testing using DR test environments into their core business processes.

Disaster recovery as a service offers so much more than peace of mind for when the worst happens, and savvy customers are really starting to make it work in their favour.