Overview of Recovery Flows

The Zerto solution enables protecting virtual machines, for both disaster recovery or for extended, longer term recovery from a retention repository, by protecting the relevant virtual machines in virtual protection groups. A virtual protection group (VPG) is a group comprised of virtual machines that are grouped together for recovery purposes. For example, the virtual machines that comprise an application like Microsoft Exchange, where one virtual machine is used for the software, one for the database, and a third for the Web Server require that all three virtual machines be replicated to maintain data integrity.

Once a VPG has been created, each virtual machine in the VPG can be replicated on the recovery site under the VRA on the host specified in the VPG definition as the host for the recovery of the virtual machine.

In addition to disaster recovery and recovery from retention, the Zerto solution enables recovery of individual files or folders from a certain point of time.

The following are described in this section:

What is Zerto’s Disaster Recovery Operation?

(On-premise environments) What is Zerto’s Test Failover Operation in On-Premise Environments?

(Azure environments) What is Zerto’s Test Failover Operation in Azure Environments?

(AWS environments) What is Zerto’s Test Failover Operation in AWS Environments?

What is Zerto’s File or Folder Level Restore?

(On-premise environments) What is Zerto’s Long Term Retention?

What is Zerto’s File System Indexing?

How is File System Indexing Managed?

What Are the Sizing and System Requirements

What is Zerto’s Search and Restore?

What is Zerto’s Disaster Recovery Operation?

Disaster recovery using the Zerto solution enables recovering from a disaster to any point between the moment just before the disaster and a specified amount of time in the past up to 30 days. The recovery is done in real time at the recovery site with a minimal RTO.

A recovery operation is one of the following:

A failover.
A planned move of the protected virtual machines from the protected site to the recovery site.
A clone of the protected virtual machine to the recovery site.
(On-premise environments) What is Zerto’s Disaster Recovery Operation in On-Premise Environments?

Virtual machines are protected in VPGs. Once a VPG is created, Zerto creates a copy under the management of a Virtual Replication Appliance, VRA, on the recovery site, of the protected virtual machine files, such as the configuration and data files. A VRA is installed on every host where the machines are to be recovered.

When a recovery operation is performed, the VRA creates the virtual machines defined in the VPG and attaches the virtual disks to these machines. It then promotes the data from the journal to the virtual machine disks.

Every write to the protected virtual machine in a VPG is copied by the VRA on the same host as the protected machine and passed to the VRA on the host in the recovery site. The VRA on the host in the recovery site was specified in the VPG definition as the host for the recovery of the virtual machine. These writes first are saved in a journal for a specified period, and then moved to replica virtual disks managed by the VRA, which mirror the protected virtual machine disks.

The following link references the appropriate procedure to protect virtual machines:

Recovery to and from: vCenter Server Protecting Virtual Machines from a vCenter Server
Recovery to and from: vCloud Director (vCD) Protecting Virtual Machines to and From vCloud Director
Recovery to and from: Hyper-V Protecting Virtual Machines from Hyper-V

After initializing the VPG, all writes to the protected virtual machines are sent by the VRA on the relevant host for each virtual machine on the protected site to the VRA on the recovery site specified as the recovery host for the virtual machine. The information is saved in the journal for the virtual machine with a timestamp, ensuring write-fidelity. Every few seconds the Zerto Virtual Manager causes a checkpoint to be written to every journal on the recovery site for every virtual machine in the VPG, ensuring crash-consistency.

The data remains in the journal until the time specified for the journal when it is moved to the relevant mirror disks, also managed by the VRA for the virtual machine. In this way, you can recover the virtual machines using the mirror disks and then promoting the data from the journal to include the final few hours of data for each virtual machine. For more details about the journal, see The Role of the Journal During Protection.

(Azure environments) What is Zerto’s Disaster Recovery Operation to Azure?

Virtual machines are protected in VPGs, which are defined in the protected site. Once a VPG is created, Zerto creates a copy of the protected virtual machines under the management of a Virtual Replication Appliance, VRA, on the Azure recovery site. The data managed by the VRA is saved in a storage account.:

When a recovery operation is performed, the Zerto Virtual Manager (ZVM) creates the following:

A copy of the virtual machine disks in a dedicated container under the same storage account.
A virtual machine in Azure, under a newly created Resource Group, with the copied disks attached to it.
Network Interfaces Cards (NICs) for each NIC of the protected virtual machine.

Once this is done, the ZVM promotes the data from the journal to the virtual machine disks.

The following link references the appropriate procedure to protect virtual machines:

Recovery from: Microsoft Azure

Protecting Virtual Machines From Azure

(AWS environments) What is Zerto’s Disaster Recovery Operation to AWS?

Every write to the protected virtual machine in a VPG is copied by the VRA on the same host as the protected machine and passed to the VRA in AWS. The VRA writes these transactions to buckets in S3. This information is ready to be written to EBS disks in EC2 when recovering from a disaster or when recovering a retention set.

Virtual machines are protected in VPGs, which are defined in the protected site. Once a VPG is created, Zerto creates a copy of the protected virtual machines under the management of a Virtual Replication Appliance, VRA, on the AWS recovery site. The data managed by the VRA is saved in an S3 bucket.

When a recovery operation is performed, the VRA creates the virtual machines defined in the VPG in EC2 and imports data from the S3 bucket as EBS disks in EC2.

After initializing the VPG, all writes to the protected virtual machines are sent by the VRA on the relevant host for each virtual machine on the protected site to the VRA on the AWS recovery site. The information is saved in the journal for the virtual machine with a timestamp, ensuring write-fidelity. Every few seconds the Zerto Virtual Manager causes a checkpoint to be written to every journal on the recovery site for every virtual machine in the VPG, ensuring crash-consistency.

The data remains in the journal until the time specified for the journal when it is moved to the relevant mirror disks in S3, also managed by the VRA for the virtual machine. In this way, you can recover the virtual machines using the mirror disks and the data from the journal to include the final few hours of data for each virtual machine. Refer to The Role of the Journal During Protection for more details about the journal.

The following link references the appropriate procedure to protect virtual machines:

Recovery from: Amazon Web Services (AWS)

Protecting Virtual Machines From AWS

(On-premise environments) What is Zerto’s Test Failover Operation in On-Premise Environments?

When testing that the recovery works as planned, the VRA creates the virtual machines defined in the VPG and uses scratch disks to simulate the virtual machine disks for the duration of the test. This enables the ongoing protection of the virtual machines and the possibility of a failover if required during the test.

(Azure environments) What is Zerto’s Test Failover Operation in Azure Environments?

When testing that the recovery works as planned, the Zerto Virtual Manager (ZVM) creates the virtual machines defined in the VPG in a dedicated resource group in Azure.

(AWS environments) What is Zerto’s Test Failover Operation in AWS Environments?

When testing that the recovery works as planned, the Zerto Virtual Manager (ZVM) creates the virtual machines defined in the VPG in EC2.

What is Zerto’s File or Folder Level Restore?

You can recover specific files and folders from the recovery site for virtual machines that are being protected by Zerto and running Windows operating systems. You can recover the files and folders from a specific point-in-time.

To recover files and folders, see Recovering Files and Folders.

(On-premise environments) What is Zerto’s Long Term Retention?

Note: You cannot restore a retention set in Azure, or in AWS.

If you need to extend the recovery ability to more than 30 days, Zerto provides Long Term Retention that enables saving the protected data in a state where they can be easily deployed.

The data is saved in a repository for a defined retention period. Each VPG will have retention sets created according to the configured schedule.

The retention process is managed by the ZVM, and the Data Streaming Service (DSS), which is installed in the VRA, performs all the data path operations. During the retention process, the DSS communicates with the VRA on the recovery site. The retention sets are restore points saved either daily, weekly, monthly or yearly in the repository. Before you can start a retention process for VPGs, you must first create one or more repositories for the retention sets.

Configuring Long Term Retention is part of defining a VPG. To set up Long Term Retention to protect VPGs, see Using Zerto’s Long Term Retention.

The number of Daily, Weekly, Monthly and Yearly retention sets define the retention period. For example, keeping 84 Monthly or 7 Yearly both result in a 7 year retention time.

This allows for full flexibility for users to define anything from a week to many years. There is no maximum to the configurable number of Yearly retentions to keep, although Zerto recommend users to keep no more than 150 retention sets in total (all types included). This means Zerto can keep up to 150 years of retention.

What does the Repository Contain?

The Repository contains Retention sets.

How does the Long Term Retention process work?

For the first time that Long Term Retention is executed for a VPG, the whole data is being read and written to the Repository (Full Retention Set).

When the second Retention process and any subsequent ones after a full Retention of the data occurs, the Retention set consists of:

All the data from the initial (Full) Retention set that hasn't changed, will be pointed as a reference.
The changed data set, that was updated between the first initial full Retention process to the Second one.

Each following Incremental Retention set will accumulate the changes between the previous run and this run, to give a complete view of the data at the point in time.

What happens when the Retention Policy period is overdue?

Retention sets are kept for the Retention period specified as part of the Retention Policy configuration. Once the Retention set expires, the expired Retention sets will be deleted from the Repository as long as it has no dependencies in other Retention sets.

What is Zerto’s File System Indexing?

To support advanced VM-level or file-level restore scenarios, Zerto offers the capability to index files and folders of selected VMs that are enabled for retention. This allows users to search for the necessary files and folders and to perform a restore of the VMs or VPGs containing those files and folders.

How Does File System Indexing Work?

How does Zerto index a VM?

Zerto uses its file system parser which is also used for file and folder recovery. Once the retention process completes, Zerto uses the journal capabilities to create a file system view on the same checkpoint that the retention process had used, and gathers information on the file system which includes file/ folder names and file sizes.

How long does it take to index?

The indexing process on its own is rather fast. Zerto can process roughly 10,000 files per second on a windows VM and about 2000 files on a Linux VM.

How is indexing enabled and disabled on a VM?

Enabling and disabling File System Indexing is done when creating or editing a VPG. See Enabling Long Term Retention for the VPGs.

Can a specific disk be excluded from being indexed?

Currently, excluding specific disks from being indexed is not supported.

What happens when the indexing repository is changed?

Zerto will start saving indexing meta data on the new repository. However, Zerto will scan all previously configured indexing repositories when searching for files and folders during Search and Restore operations.

What happens when the indexing repository is removed?

Users can select “None” as an indexing repository. If there are still VPGs which have VMs that have been selected for indexing, the indexing process for these VMs will fail. It is recommended to clear the indexing settings from all VMs if one chooses not to use indexing anymore.

What happens when the indexing repository is re-added?

If the repository was completely removed from Zerto, then the indexing data is lost. Upon re-adding the repository, any indexing data which exists on that repository is ignored and cannot be leveraged for Search and Restore.

Is indexing executed in parallel on all VMs?

No. In order to guardrail resources in the environment, Zerto limits the number of parallel indexing to 3 VMs and 1 per VRA at most.

How is File System Indexing Managed?

How can users leverage the data kept in the indexing repository?

All the indexed data is kept in the repository and is used when performing Search and Restore. Users can search for files or folders in VMs that were indexed, in a specific date range, select revisions of the specific file or folder in question, and restore the VM or VPG to the selected restore point.

When does the indexing process happen?

As part of the retention process, once the system finishes saving the retention sets of all the VMs in the VPG on the repository successfully, Zerto initiates indexing the VMs that were selected for indexing in the VPG.

Will it affect retention performance or replication?

Zerto guardrails the replication so any other process will not be affected, and that includes indexing. Indexing is done on the ZVM machine using a service called VBA. The VBA is limited to run 3 indexing tasks in parallel at most, and not more than one VRA. The impact on each VRA is similar to having a single VM mounted for File Level Restore.

How do I know when indexing is running?

When the indexing process runs, there will be a task showing the VPG is being indexed.

Can an indexing task be aborted?

Yes. As with any other task in Zerto, if you wish to stop the indexing process, you can stop the task by clicking the stop button. See Monitoring Tasks.

What happens if a retention process starts while the indexing task is running?

Zerto cannot run two tasks on the same VPG, therefore the retention process will wait for the indexing process to complete before it starts.

What happens when indexing fails?

The indexing task will be shown as “failed”. When searching for files/folders, no results from the failed restore point will be shown.

When is the indexed data removed from the system/repository?

In Zerto 7.0, Zerto does not remove the indexed data from the system or the repository. In one of the upcoming updates or versions, Zerto will remove indexed data from both the system and the repository, when the retention-set has been expired. See Storing Retention Sets for further details.

What happens if the indexing task fails?

When the indexing task fails, there will be a task showing that VPG which was being indexed.

Is the data removed when the VPG is deleted?

Indexed data is not deleted from the system, and as such users will be able to search files/folders in VMs even if the VPG protecting these VMs were deleted. In fact, as long as the retention-set that the indexing is referencing still exists, results will show up in Search and Restore operations.

What happens to the indexed data when re-installing Zerto?

Zerto does not delete the indexed data. Similarly to the remove repository process, the previously indexed data cannot be leveraged and will not be referenced in the new installation. This is planned to be addressed in one of the upcoming versions.

What Are the Sizing and System Requirements

Which Operating and file systems are supported?

Operating Systems, File Systems and Volume Manager that Zerto can index:

Operating Systems: Windows Vista and 2008 server and above and Linux
File System and Volume Manger: NTFS and EXT2/EXT3/EXT4
Supported partitioning methods: GPT, MBR

What happens if only one volume is supported and another one is not?

Zerto indexes the supported volumes and skips the non-supported volumes one we don't except to log it exists and wasn't supported.

What is the maximum number of entries that can be indexed on a single VM?

A VM with over 150 million entries (files or folders) cannot be indexed.
Rate of entries (files or folders) indexed in NTFS per second: 2000 files.
Rate of entries (files or folders) indexed in EXT per second: 1500 files.

How to estimate the size required for indexing?

Storing the index for 100 restore points (incremental or full) will consume between 5-10% roughly of the original VM size.

What is Zerto’s Search and Restore?

Search and Restore allows the user to quickly search for files and folders in specific VMs and restore either the virtual machine or VPG once the desired restore point is identified.