Skip to main content

Onboarding for Veeam Recovery Orchestrator - Step 7 Testing orchestration plans & configuring reports


Testing Orchestration Plans

Review the content in this section and pay close attention to key considerations when leveraging DataLabs for Orchestration Plan testing.

Manually Testing Orchestration Plans

The on-demand plan testing portion of the Veeam Recovery Orchestrator allows you to test the recovery of virtual machines inside of an isolated bubble. We've previously covered Virtual Labs and DataLabs in this training. These are the core components utilized to test orchestration plans.

 

Running an Orchestration Plan

After you configure a restore plan, run a successful readiness check, and a DataLab test. The plan can be considered ready for restoration. You can invoke the various actions below for the plan, depending upon the current plan state.

  • Schedule a time for the plan to execute restore.
  • Run the plan to execute restore immediately.
  • Halt the plan to interrupt its execution.
  • Reset the plan to clear the current state and allow it to run again.

We can schedule or manually run a replica plan at any time. Before we failover to the replica VM, our replica plan will first shut down the source VM. The failover state is considered temporary and needs to be finalized.

The steps below will walk you through the Failover and Undo Failover procedures. You will monitor this from the Orchestrator UI, vSphere Client, and Veeam Backup & Replication Console.

  • Permanent Failover (to DR): VM replicas in the DR site will no longer be treated as replicas. Restore point snapshots will be deleted, and the source VMs will be removed from the replication jobs. Choose this option if your Production site has been destroyed and failing back is not an option.
  • Failback (to Production): You've been running from the replicas in the DR site, and you'd like to replicate the changes back to the Production VMs and test the changes. This is also considered a temporary state, and you will need to either commit the changes or Undo Failback and discard the changes to the Production VMs.
  • Undo Failover: You have failed over to the replica VMs in the DR site. Changes were made to the replicas while powered on and saved to VM snapshots. Undo Failover will discard the changes and shut down the replicas. You can power on the Production VMs again when ready.

 

Permanent Failover Procedure:

  • Enable and run a recovery plan
  • Use the latest Restore Point
  • Monitor the Failover process

 

Failover and Failback Procedure:

  • Enable and run a recovery plan
  • Use the latest Restore Point
  • Monitor the Failover process
  • (2) Options after failover is complete:
  • Commit the changes
  • Undo Failback

 

Failover and Undo Failover Procedure:

  • Enable and run a recovery plan
  • Use the latest Restore Point
  • Monitor the Failover process
  • Click Undo and observe the Undo Failover process

 

Suggested resources:

 

Understanding Reports

Start by watching this walkthrough of the Veeam Recovery Orchestrator dashboard and learn how to use its powerful reporting and documentation features.

 

Deployment Checklist:

  1. Configure a Custom Report Template to be used for Orchestration Plans. Refer to the attached link.
  2. Go back and edit your Orchestration Plans to use the new Custom Template if you create one.
  3. Run additional tasks and review reports for a full understanding of reporting capabilities.

Custom Reports

Veeam Recovery Orchestrator reports are all based on a Veeam Default Template. This report can be cloned and edited in Word to add custom information (e.g.: custom company logo).

 

Types of Reports

Orchestrator automatically generates reports at different stages of a plan’s lifecycle (creation, test, execution). There are four types of reports that are generated based on existing or customized templates:

 

1. Plan Definition Report

This shows all VM groups, plan steps, and parameters defined by the plan. This document is ideal for auditors and managers and can be used to obtain sign-off from application owners who need to verify the plan configuration.

By default, Orchestrator runs the Plan Definition Report automatically for every ENABLED orchestration plan at 7:00 AM daily. You can also generate the report on demand by running the Update Definition Report.

2. Plan Readiness Check

This is a very low-impact and fast method to confirm that the configuration of an orchestration plan matches the DR environment, and therefore the plan should run successfully. This check completes very quickly. The orchestrator server runs the readiness check automatically for every ENABLED orchestration plan at 8:00 AM daily. You can also run this manually by selecting Run Readiness Check.

3. DataLab Test Results

This contains test execution details and provides information on the configured test environment.

4. Plan Execution History

This contains plan performance details and provides information on each processed VM and any errors encountered during the plan execution.

 

By default, all Orchestrator reports are generated with the highest level of detail. To minimize the load on the server and filter the report output, you can specify less granular report settings.

 

Suggested resources:

 

If you need more help getting started, you can post your question in the comments section below or contact us at any time and someone from the Customer Success team will be there to assist you. 

 

Continue to Summary of useful resources

Return to Course Overview

Comment