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.

The following are described in this section:

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:

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.

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”, on page 41.

 

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.

To recover files and folders, see “Recovering Files and Folders”, on page 358.

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”, on page 365.

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.

The Repository contains retention sets, where each retention set has it’s own mapping file (DOM file).

When Long Term Retention is first configured, and the first reading of the data has occurred, the retention set consists of:

When the second reading and any subsequent readings after a full retention of the data occurs, the retention set consists of:

Each incremental retention set is independent of previous incremental and full retention sets, and gives a complete and total picture of the data at the point in time of the reading.

Retention sets are kept for the retention period specified as part of the Retention Policy configuration. Once the retention expires, the expired retention sets will be deleted from the Repositories.

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.

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.

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.

Enabling and disabling File System Indexing is done when creating or editing a VPG. See “Enabling Long Term Retention for the VPGs”, on page 372.

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

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.

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.

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.

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.

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.

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.

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.

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

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”, on page 224.

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

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.

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

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.

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.

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

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

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

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.