vRanger 7.6.4 - User Guide

Adding a Quest DR Series system as a CIFS repository

Adding a Quest DR Series system as a CIFS repository

 

NOTE: Adding a Quest DR Series system as a CIFS repository does not take advantage of the full function of the DR Series system. Quest recommends adding the Quest DR Series as an RDA repository.

To add a Quest DR Series system as a CIFS repository:

1	In the My Repositories pane, right-click anywhere, and click Add > Windows Share (CIFS).

2	In the Add Windows Network Share Repository dialog box, complete the following fields:

▪	Repository Name: Enter a name for the repository.

▪	Description: [Optional] Enter a long-form description for the repository.

▪	User Name and Password: Enter the credentials for accessing the CIFS share.

▪	Security Protocol: Select a protocol, NTLM (default) or NTLMv2.

▪	Server: Enter the UNC path to the desired repository directory. Alternatively, you may enter a partial path and click Browse to find the target directory.

 

NOTE: You must enter a valid username and password before using the browse functionality.

 

IMPORTANT: Do not select Encrypt all backups to this repository. Using encryption or compression with deduplicated repositories limits or disables deduplication. Encryption and compression should not be used with any repository type that provides deduplication.

3

Click OK.

The connection to the repository is tested and the repository is added to the My Repositories pane and the Repository Information dialog box.

vRanger checks the configured repository location for existing manifest data to identify existing savepoints.

4	If vRanger finds existing savepoints, click the applicable button:

▪	Import as Read-Only: To import all savepoint data into the vRanger database, but only for restores, click this button. You cannot back up data to this repository.

▪	Import: To import all savepoint data into the vRanger database, click this button. vRanger is able to use the repository for backups and restores. vRanger requires read and write access to the directory.

▪	Overwrite: To retain the savepoint data on the disk and not import it into vRanger, click this button. vRanger ignores the existence of the existing savepoint data and treats the repository as new.

5	Click Next.

Adding a Quest DR Series system as an NFS repository

Adding a Quest DR Series system as an NFS repository

 

NOTE: Adding a Quest DR Series system as a Network File System (NFS) repository does not take advantage of the full function of the Quest DR Series system. Quest recommends adding the Quest DR Series as an RDA repository.

To add a Quest DR Series system as an NFS repository:

1	In the My Repositories pane, right-click anywhere, and click Add > NFS.

2	In the Add Network File Share Repository dialog box, complete the following fields:

▪	Repository Name: Enter a descriptive name for the repository.

▪	Description: [Optional] Enter a long-form description for the repository.

▪	DNS Name or IP: Enter the IP or FQDN for the repository.

▪	Export Directory: Specify the export directory, which is similar in concept to a network share. You must create a target subdirectory in the export directory.

▪	Target Directory: Specify a subdirectory of the NFS export directory. This directory is the location to which savepoints are written.

 

IMPORTANT: Do not select Encrypt all backups to this repository. Using encryption or compression with deduplicated repositories limits or disables deduplication. Encryption and compression should not be used with any repository type that provides deduplication.

3

Click OK.

The connection to the repository is tested and the repository is added to the My Repositories pane and the Repository Information dialog box.

vRanger checks the configured repository location for existing manifest data to identify existing savepoints.

4	If vRanger finds existing savepoints, click the applicable button:

▪	Import as Read-Only: To import all savepoint data into the vRanger database, but only for restores, click this button. You cannot back up data to this repository.

▪	Import: To import all savepoint data into the vRanger database, click this button. vRanger is able to use the repository for backups and restores. vRanger requires read and write access to the directory.

▪	Overwrite: To retain the savepoint data on the disk and not import it into vRanger, click this button. vRanger ignores the existence of the existing savepoint data and treats the repository as new.

 

Understanding the vRanger virtual appliance (VA)

Understanding the vRanger virtual appliance (VA)

The vRanger VA is a small, pre-packaged Linux® distribution that serves as a platform for vRanger operations away from the vRanger server. With VAs, the workload can be spread across the other CPUs available to a host. This feature provides increased reliability and scalability over operations.

vRanger uses the VA for the following VMware® functions:

•	Replication to and from VMware® ESXi™ hosts.

•	File-level restore (FLR) from Linux machines.

•	Optionally, for backups and restores.

 

NOTE: The VA is not designed to be used with Hyper-V® machines.

The VA must be deployed to any ESXi host that you want to configure for replication — either as a source or a destination. For hosts in a cluster, you may deploy just one VA to the cluster; the VA is shared among the cluster’s hosts. When deploying a VA to a cluster, you must choose a host in the cluster to which the VA should be associated.

In addition, replication by way of a VA requires that if a VA is used on one host or cluster in a replication job, a VA must be used on both the source and destination host or cluster. In other words, VAs, when used for replication, must be used in pairs.

When configuring the VA, consider the amount of resources — CPU and RAM — allocated to the VA as the number of simultaneous tasks the VA can process is directly tied to available resources. In addition, if you want to perform replication tasks using a VA, carefully consider an appropriate size for the VA scratch disk. For more information, see The VA scratch disk.

For more information about vRanger VA configuration, see the following topics:

•	The VA scratch disk

•	Deploying the VA by using the Virtual Appliance Deployment Wizard

•	About deploying multiple VAs

•	Changing the VA configuration

•	Configuring VA networking

•	Disabling Distributed Resource Scheduler (DRS) for the vRanger VA

The VA scratch disk

The VA scratch disk

If you want to perform replication tasks with your VA, you need to add a second “scratch” disk to the VA. This scratch disk is used to store two types of files:

•

vzmap files: Block maps — in the form of a vzmap file — for the VMs replicated to the destination host. This file contains block map information, and not actual data blocks. These maps are compared to the source VM during each replication to identify the data blocks that have changed since the last replication. The vzmap files make differential replication faster as they remove the need to scan the destination VM blocks for comparison with the source VM.

•

vzUndo files: As data is sent to the destination host, by using the VA, blocks in the destination disk are written to the undo file before they are overwritten by the changed data. If replication fails and an undo becomes necessary, the original destination disk blocks are read from the undo file and written to the destination disk to roll back the failed replication. This process is a key function designed to provide resiliency in the face of a network failure; if there is a network failure during the replication pass, the destination VM is not corrupted by incomplete data.

After the replication is complete, and all data has been received by the destination VA, the undo file is deleted. At that point, the storage space used by the undo file is returned to the VA for use. Undo files are not created during the first replication. During the first replication, the entire VM is sent to the destination host, but there is no existing data on the destination VMDKs, and therefore no risk of corruption. Data is streamed directly to the VMDK. You do not need to allocate scratch disk space for this scenario.

While the vzmap files are trivial in size, in the order of a few MB, the undo file can potentially be as large as the VM itself. While the scratch disk needs to be configured to a size sufficient to handle the data of concurrent replication tasks, making it too large wastes valuable storage space. Use the following topics to guide you in determining the proper size for the scratch disk.

•	Strategies for sizing the scratch disk

•	Options for a smaller scratch disk

•	The scratch disk on the source host

•	Scratch disk location