In the wake of Hurricane Harvey, after unprecedented amounts of flooding have finally begun to recede from the Houston area, I wanted to avoid focusing on the disastrous event itself. It would be doing those impacted by the storm a disservice to write a commentary on protecting data, after a time where protecting loved ones was significantly more important. Instead, I wanted to share other reasons why it would be beneficial to have a solid DRaaS (Disaster Recovery as a Service) plan in place.
We all know that geographic redundancy, and replicating critical workloads can keep businesses up and running during events such as Harvey, but there are many more use cases for DRaaS than just natural disasters and a key one is testing. Testing a DR plan can ensure that when the unforeseen happens, your business is ready. Beyond readiness, however, there are a few other key reasons why testing can be important for your business.
When delivering Zerto for DR solutions for our customers, iland creates an environment on our Secure Cloud with preconfigured networks for both live and test failovers. The test network 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. In addition to typical DR testing, there are a number of use cases for leveraging that isolated environment. I’m going to shed some light on the following three use cases for DR testing:
Security / Penetration Testing
Let’s face it, as fearful of security events as we all are at this point, many organizations are also scared of impacting critical systems by performing security checks on their production systems. Having an isolated environment to conduct security tests is invaluable. iland’s Secure Cloud offers a litany of security tools, reportable compliance metrics, multi-factor authentication, encryption of data at rest, and role-based access control.
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. Unbeknownst to you, there might be critical vulnerabilities present on those systems. You’ll be able to run a vulnerability scan from iland’s Secure Cloud Console, potentially identifying chinks in your systems’ armor. Following that, you could inject sample malware into the environment to test against our Trend Micro Deep Security suite’s capabilities in regards to detection. Other tools worth checking against 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 this DR security testing use case. “Hack” away my friends!
Code Development / Quality Assurance
These days, almost all organizations 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 propensity to release code a bit too hastily. 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 times, 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 from having to issue patches down the line and 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. If so, then why not test the patches, or any other code changes for that matter, in a test environment? We’ve had a number of customers find this environment conducive to finding issues and bugs much sooner.
Many customers will adopt a crawl, walk, run strategy when moving to the cloud. Leveraging replication to the cloud can be a stepping stone to cloud adoption. A test environment could be a foray into setting up a true cloud-based testing and development environment, but I’ll leave that for another blog post. In the meantime, use the power of Zerto and the integration into our Secure Cloud to know that development can be done in isolation.
As you can see, I’ve identified a few, pretty cool, use-cases for DR testing. In doing so, I mentioned Zerto and iland’s Secure Cloud. I’d encourage you to learn more if you’re unfamiliar. Keep in mind, that setup, installation, and configuration of Zerto is extremely seamless, and some iland customers have adopted a phased approach to protecting their environments. At a minimum, organizations should consider protecting their most mission-critical workloads to start. Natural disasters, again, might prompt organizations to consider DR, but don’t forget some of the added benefits of adopting a regular testing cadence. Keep in mind, that with iland’s cost-conscious approach to DR events, you only pay for resources you consume. To wrap this up, I just have one question, and one comment:
What other use cases have you come across? Feel free to respond in the comments section below. Thanks in advance!
To conclude, please keep Houston, Texas, and the entire Gulf Coast region in your thoughts and prayers as they begin the recovery process.
