One question I answer on a regular basis “What is Veeam Disaster Recovery Orchestrator?”.
I thought I would take a little bit of time to set the stage and level set and give you an overview of what Orchestrator does.
Veeam Disaster Recovery Orchestrator Under the Covers
The first thing to understand is that Orchestrator works with Veeam Backup & Replication.
The protection jobs you have configured today from your most mission critical applications protected Veeam CDP to regular Veeam replicas to your backups to integration with some enterprise storage arrays will be used by Orchestrator.
You don’t need to recreate them, but you will need to create an orchestration plan which is essentially a disaster recovery plan. To do this you’ll use the Orchestrator UI, which is a really simple to use.
The HTML5 interface that runs you through a wizard with just a couple of steps to create a disaster recovery plan.
After you’ve created an orchestration plan with this wizard, you’ll be able to unlock two of Orchestrator’s most powerful features, testing and documentation.
Let’s face it, DR has a reputation of being boring, time intensive, and quite frankly depressing.
Orchestrator automates the most horrible parts of disaster recovery and makes disasters much more simple to prepare to.
I really want to start by focusing on testing and documentation because those are my two favorite things to talk about.
Fully Automated Disaster Recovery Tests
Let’s start with testing.
Orchestrator is going to leverage Veeam DataLabs which are a construct of Veeam Backup & Replication. Within your Backup & Replication console, you configure a Virtual Lab and then simply map it into Orchestrator.
Now, if you’re not familiar with DataLabs, there’s a lot of great resources out there.
Here are some of my favorites, but long story short, they allow for an isolated environment that’s non disruptive to production, isolated from production, re-uses your backup data, and makes use of those recovery resources.
Getting Started with DataLabs
This is a great environment of course for disaster recovery testing, but it’s also great for things like patch testing, security, traffic security testing, training, new people are just plain old wreaking havoc (not that I’ve done that, of course).
These disaster recovery tests can be run on demand or on a scheduled basis and they’re completely automated.
It’s a matter of a couple of simple clicks and the test runs itself at the end, a document will be generated.
This test document can be automatically be emailed to key stakeholders, your application owners, CIO, whoever should know that this application has tested successfully will automatically be notified.
Now, let’s say that your test wasn’t successful, you can consume this information a couple of different ways.
You can go through the Orchestrator UI and just follow the trail of red Xs to figure out what went wrong in your environment or you can simply read test report.
The best part of this is when there is some kind of error or warning orchestrator is very good at telling you what was wrong or what went wrong or what broke, making it easy fix it and run your test again.
Testing Your Backups
There are two types of tests when it comes to restore plans, or restoring from your backups.
There’s a quick test which leverages Veeam’s instant VM recovery technology and there’s also a full test that will do full restores.
Now this quick test is fantastic. If you’ve set up a new restore plant and you just want to make sure everything’s working.
But if you actually want to test your real world RTO, and know for sure how long it will take to recover, then you can run that full test. You can also switch your recovery location when running a DR test.
For example, if you have different vSphere environments with different storage to see how those numbers would be impacted based on where you’re restoring to. This makes it easy to make the best decisions for where to recover those workloads.
When it comes to regular replicas or storage replication anytime you run a disaster recovery test, that is your real world test right there, there aren’t any options for you to choose since your data is already in your recovery site in your vSphere environment just waiting to be powered on. Replication technologies of course provide a very aggressive RTO.
Documentation Done for You
Besides the test report, there’s three other documents for a total of four documents.
There is the plan definition report, which is just Orchestrator’s way of saying disaster recovery plan. This report lists every VM in your plan, it lists what steps are taken on each VM.
It goes into detail on what those steps are and it tells you where the VMs will be recovered to (what your recovery location is) or if you’re using replication what your destination environment is. At the end of this document, there’s also a full change log to please the auditors.
Next is the readiness check. A readiness check runs automatically on plan creation and can be scheduled to run on a daily basis (or any time you feel like it. It is a lightweight check of your environment to check two main things. First is your RPO, because we always need to make sure we are able to meet it. If you aren’t for any reason it will flag you, flag it and tell you why.
Orchestrator will also look at your recovery resources. For example, if you have a host that is suddenly down or maintenance mode orchestrator will let you know there’s something going on with your recovery location that will impact your ability to recover. The check is also going to make sure things like your networks are mapped correctly, that your host can see your storage in the case of storage plans. It really is going to examine many nuances that need to be configured correctly for successful recovery.
Last but not least is, one document I hope that no one ever has to look at and that of course it’s a plan execution report.
If you actually had to an orchestration plan in the event of a disaster, you would get a fully documented report that told you here’s what happened, here’s the steps we ran and everything was successful. Of course, everything is going to be successful on disaster day because we’ve tested and checked this plan all the time and we are confident that we’re going to be able to recover.
There’s a lot of cool stuff that orchestrator does beyond this.
But for me, it really comes down to testing and documentation because these are two of the traditionally most difficult areas of a disaster recovery plan, and really what prevents organizations from being able to have a proven DR plan in place.
Melissa is an Independent Technology Analyst & Content Creator, focused on IT infrastructure and information security. She is a VMware Certified Design Expert (VCDX-236) and has spent her career focused on the full IT infrastructure stack.