Adding a Quest DR Series system as a CIFS repository
To add a Quest DR Series system as a CIFS repository:
1
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.
▪
▪ 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.
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.
▪ 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
To add a Quest DR Series system as an NFS repository:
1
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.
▪ 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)
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.
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
• 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.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.
© ALL RIGHTS RESERVED. Conditions d’utilisation Confidentialité Cookie Preference Center