Chat now with support
Chat with Support

vRanger 7.8 - User Guide

Introduction Configuring vRanger
Configuration overview Configuring vRanger through the Startup Wizard Configuring vRanger manually Supplemental instructions: additional repository types
Using vRanger Backup Restore Replicate VMs Reports Integrating and monitoring vRanger Using the vRanger Console vAPI Cmdlet details
Add-BackupGroupEntity Add-BackupJobTemplate Add-CIFSRepository Add-DdbReplicationRepository Add-DdbRepository Add-EsxHost Add-HypervCluster Add-HypervHost Add-HypervRestoreJobTemplate Add-NFSRepository Add-NVSDRepository Add-PhysicalMachine Add-RdaRepository Add-ReplicationJobTemplate Add-RestoreFromManifestJobTemplate Add-RestoreJobTemplate Add-VirtualAppforLinuxFLR Add-VirtualAppforLinuxFLRVA Add-VirtualCenter Disable-Job Dismount-LinuxVolume Enable-Job Get-AddressBook Get-BackupGroupEntity Get-CatalogSearchData Get-CatalogStatus Get-ConfigOption Get-Connection Get-CurrentTemplateVersionID Get-Datastore Get-GlobalTransportFailover Get-InventoryEntity Get-IsInventoryRefreshing Get-Job Get-JobTemplate Get-MonitorLog Get-Network Get-PhysicalMachineDiskMap Get-Repository Get-RepositoryJob Get-RepositorySavePoint Get-RestoreDiskMap Get-SavepointDisk Get-SavepointManifest Get-Savepoints Get-TransportFailover Get-VirtualApplianceConfig Get-VirtualApplianceDeploymentStatus Get-VirtualApplianceReconfigStatus Get-VirtualMachinesUnderInventory Get-VmDisk Get-VMDKVolume Install-VirtualAppliance Mount-LinuxVolume New-BackupFlag New-BackupGroupMember New-Daily Schedule New-EmailAddress New-IntervalSchedule New-MonthlySchedule New-ReplicationFlag New-RestoreFlag New-SMTPServer New-TransportConfiguration New-VirtualAppliance New-WeeklySchedule New-YearlySchedule Remove-AllMount Remove-BackupGroupEntity Remove-BackupGroupMember Remove-Catalog Remove-DdbStorageUnit Remove-JobTemplate Remove-LinuxVolume Remove-Repository Remove-SavePoint Remove-VirtualAppliance Remove-VirtualApplianceConfiguration Run-JobsNow Run-ReplicationFailover Run-ResumeReplicationFailover Run-TestReplicationFailover Set-Cataloging Set-CBTonVM Set-LinuxVolume Set-MountPath Set-Resources Stop-vRangerJob Update-BackupJobTemplate Update-GlobalTransportFailover Update-HypervRestoreJobTemplate Update-Inventory Update-ReplicationJobTemplate Update-RestoreJobTemplate Update-VirtualAppliance Update-VirtualApplianceConfiguration
About us

Replicate VMs

Previous Next



vRanger includes integrated replication based on the proven technology of vReplicator, enabling replication of VMware® virtual machines (VMs) both on site and at remote locations for flexible and efficient disaster recovery preparedness. Combine backup and replication jobs to ensure that you meet your organization’s recovery time and recovery point objectives. Perform fast VM failover and recovery at all your sites, no matter where they are located.
NOTE: Replication is not available for Hyper-V® VMs.

If you are looking for information on replicating Quest RDA and EMC DD Boost repositories, see Managing repository replication.

Understanding replication of VMs

Previous Next


Replicate VMs

vRanger includes integrated replication based on the proven technology of vReplicator, enabling replication of VMware® virtual machines (VMs) both on site and at remote locations for flexible and efficient disaster recovery preparedness. Combine backup and replication jobs to ensure that you meet your organization’s recovery time and recovery point objectives. Perform fast VM failover and recovery at all your sites, no matter where they are located.
NOTE: Replication is not available for Hyper-V® VMs.

If you are looking for information on replicating Quest RDA and EMC DD Boost repositories, see Managing repository replication.

How replication works

Previous Next



Table 2. Working files
Records data block offset and hash of files on the target VM. A .vzmap file is created for each of the files replicated at the end of the replication. The .vzmap file is used by the next replication pass to detect any data changes since the previous pass. It stays on the target VM as long as the job is still configured to run. While relatively small, the size of the .vzmap file is directly proportional to the size of the VMDK it is based on.
During replication, the .vzmap file is stored on the target VA.
NOTE: The .vzundo file is as large as the amount of changed data replicated during a given pass. For example, if a replication pass sends 20 GB of changed data to the target VA, the .vzundo file is 20 GB.
Active block filter file. One for each hard disk data file when ABT is enabled. It records active data block offsets for source VM disks. This file is used against the .vzmap file to figure out data blocks that need to be streamed to the target. It is created at the start of the replication process and removed when disk replication is completed.
Disk data filter file. One for each hard disk when one of two situations are true: CB is enabled, or both AB and CB are enabled. It contains active and changed data block offsets that need to be compared to the .vzmap file at the target to figure out data blocks that need to be streamed to the target. It is created right before file replication starts and removed when file replication is completed.
vRanger supports VMware® ESXi™ replication by way of the vRanger VA, which leverages the VMware® HotAdd disk transport mechanism. After the VAs are configured and deployed, the use of the VA is automatic and transparent. The following lists some key points about replicating with the VA:
For instructions on deploying and configuring the VAs, see the Quest vRanger Installation/Upgrade Guide.
The VM hardware cannot be changed during replication. For this reason, the VM must be at a hardware version level that is compatible with both the source and target servers. The VMware® ESXi™ version of the source and target hosts does not matter, as long as the VM hardware is supported on both ESXi versions. For more information on VM hardware versions and compatibility, see the VMware documentation at https://www.vmware.com/support/pubs/.
If you make hardware changes on the source VM, you need to configure the target VM in the same way before the next replication pass. You might also need to edit the replication job to include the new hardware.

Replication modes

Previous Next


Replicate VMs > Replication modes

vRanger offers Replication with Changed Block Tracking (CBT) or standard Differential replication. Each of these replication modes has the option of ABM. VM replication in general starts with replicating the source VM to the target host. Changes are applied to the target VM at user designated intervals to keep the target in sync with the source. Thus the key difference between the replication modes is how vRanger identifies VM changes to replicate. For more information, see the following topics:
Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating