Meet NAKIVO Backup & Replication v8.0 with Site Recovery

Excellent news! We have just released NAKIVO Backup & Replication 8.0 and entered the market of enterprise-grade disaster recovery solutions. This latest version includes advanced Site Recovery functionality, which is a powerful disaster recovery tool for VMware, Hyper-V, and AWS EC2 environments. The feature allows you to build automated recovery workflows, test them non-disruptively to make sure you meet your RTOs, and perform one-click planned or emergency failover – all from a single convenient web intarface. We are going to explore the new advanced functionality in a series of blog posts. If you can’t wait to try it out, you can download the full-featured Free Trial right now.

Introducing Site Recovery by NAKIVO

Site Recovery was designed to orchestrate and automate the VM disaster recovery process. The feauture lets you build custom recovery workflows (i.e., Site Recovery jobs) from a set of available actions, including:

Failover for VMware VMs, Hyper-V VMs, and AWS EC2 instances (You can fail over to a previously created replica)

Failback for VMware VMs, Hyper-V VMs, and AWS EC2 instances (You can transfer workloads back from a replica at a DR site to the source VM or instance once your primary site is useable again)

Start VMware VMs, Hyper-V VMs, or AWS EC2 instances

Stop VMware VMs, Hyper-V VMs, or AWS EC2 instances

Run jobs (You can run any jobs you have created)

Stop jobs (You can stop a job that is already running)

Run script (You can execute any script on Linux or Windows machines)

Attach repository (You can attach a backup repository)

Detach repository (You can detach a repository that is already attached)

Send email (You can send an email message notifying interested parties if an action completes successfully or fails)

Wait (You can wait for a specified time period before moving on to the next action in the job’s workflow)

Check condition. Before proceeding accordingly, you can check any of the following conditions:

  • whether a specific VM/instance exists
  • whether a specific VM/instance is running
  • whether a host is reachable

The actions can be run in any order that suits your current recovery needs and procedures.

Test Mode and Production Mode

A Site Recovery job can be run in test mode or in production mode. The main purpose of test mode is to check whether your VMs can be recovered according to your disaster recovery plan within your target time frames (RTOs). When running a Site Recovery job in test mode, actions such as Start/Stop VMs, Failover/Failback, and Attach/Detach Repository are reverted as soon as the test run is complete. This brings the environment back to its initial state so that it remains ready for the job to be run in Production Mode when necessary. When a Site Recovery job is run in production mode, your virtual environment is recovered (e.g., after a disaster) and the actions are not reversed upon job completion. The source VM can be powered off and workloads migrated to VM replicas at the disaster recovery site.

Site Recovery Steps

The entire recovery process performed with Site Recovery should consist of several steps, including VM replication, building a workflow, testing the workflow, running the failover, and then reverting to the previous state (i.e., running the failback). Your specific approach, however, will depend on the specific needs of your company.

Setting Up VM Replication

Having a replica is a prerequisite for failover action in the framework of Site Recovery. NAKIVO Backup & Replication can replicate your VMs or instances efficiently using an application-aware approach. Select which source VMs/instances should be replicated, then define the target server and datastore for the replicas.

Creating a Recovery Workflow

To create a Site Recovery job, simply compose a logically correct sequence of actions using the options listed above. For example, you could assemble the following workflow:

  1. Fail over VM1 to its replica at the DR site
  2. Check state: Check that VM1 is running. If VM1 is running, proceed to the next step
  3. Wait for 5 minutes
  4. Fail over VM2. For the purposes of this example, suppose VM2 needs VM1 to be running in order to function properly (e.g., VM1 runs the SQL database on which VM2 depends)
  5. Check state: Check that VM2 is running. If VM2 is running, proceed to the next step
  6. Run a script on VM2
  7. Send email: Inform the departmental staff that failover has been executed successfully

This is a simplistic example designed to give you an idea of how a basic VM failover DR workflow would work with NAKIVO Backup & Replication. You can create multiple Site Recovery jobs for different situations. This approach makes disaster recovery more flexible and helps you recover your virtual infrastructure, along with the services that run on it, faster.

Performing Failover Testing

As mantioned above, a Site Recovery job that includes failover actions can be run in test mode. Best practices dictate that you should run a Site Recovery job in test mode once it is created. This way, you can ensure that the job works as planned and everything can be recovered successfully in the appropriate period of time. You can schedule a Site Recovery job to run periodically in test mode. If you want to run a Site Recovery job in production mode, you should initiate the job manually.

Running Failover

Failover is the process of switching from a failed VM at the production site to a VM replica at a DR site. Failover is one of the actions available for Site Recovery job. A source VM can be gracefully powered off during failover with NAKIVO Backup & Replication’s Site Recovery functionality. The Power off source VM option may be useful when a source VM is still powered on but is working improperly after disaster.

Performing Failback

Failback is the process of restoring workloads to a source VM from a VM replica that was used for disaster recovery. The failback process is essentially the reverse of the failover process. After failover to replica, all changes are written in the replica at the DR site. When the production site is recovered, the workloads should be transferred back to there. The source VM must be synchronized with its VM replica to update the source VM state, as new data (since failover) has been written only to a VM replica. A failback operation replicates that data from the VM replica back to the source VM.

The Advantages of Site Recovery as a Disaster Recovery Tool

Comprehensive DR orchestration and automation. Site Recovery allows you to implement disaster recovery plans with high levels of automation. You can define the order of VM recovery in consideration of VM dependencies so that when disaster strikes, recovery is as efficient as possible.

Flexibility to accommodate the needs of various businesses. You can create multiple Site Recovery jobs according to your needs. The set of actions available for incorporation into Site Recovery jobs allows to create different recovery workflows custom tailored for different situations.

Built into the data protection solution. Site Recovery is a feature included in NAKIVO Backup & Replication and available along with the rest of the product’s comprehensive feature set; you don’t need to buy a separate license for Site Recovery. With this solution, all data protection and disaster recovery activities are managed from a single pane of glass.

Significant savings compared to other DR solutions. NAKIVO Backup & Replication, with the built-in Site Recovery tool, is a cost-effective solution. The product continues to please users with useful new features while keeping the same affordable prices – especially when compared with the competitors on the disaster recovery market.

Follow our blog to get detailed information on the steps required for comprehensive Site Recovery planning and make sure to download a full-featured Free Trial to try Site Recovery in your own virtual environment.

Meet NAKIVO Backup & Replication v8.0 with Site Recovery
5 (100%) 4 votes

Share:

LinkedIn Google+