Remote DS-VDR
The Remote DS-VDR feature can be configured for Microsoft Hyper-V Server and VMware vCenter Server backups to allow users to initiate disaster recovery restores for virtual machines. The backup must be of an entire virtual machine that is already stored in the DS-System online storage.
IMPORTANT: Remote DS-VDR is not supported for Microsoft Hyper-V Server cluster configurations.
Remote DS-VDR must be licensed for the DS-System from the DS-License Server in the form of an incremental counter called the Remote DS-VDR count. The DS-System administrator can assign the license count to DS-Client accounts individually from this pool. Remote DS-VDR is a service that runs on a remote Windows or Linux computer and can be configured using the DS-Operator.
NOTE: You must install the Remote DS-VDR Tool on a Remote DS-VDR computer and the service or daemon must be running. For instructions on how to install the Remote DS-VDR Tool, see the Server Software Installation Guide.
Since Remote DS-VDR only supports restoring master or delta generations and not regular files, DS-Client users must configure the backup with three or more generations. When a backup is scheduled for a Remote DS-VDR restore, the latest backed up generation is automatically restored to a standby virtualization server. In the event of a disaster or other unforeseen event, you can immediately switch to the standby virtualization server. The DS-System can connect to multiple Remote DS-VDR services, thereby distributing the load.
The configuration and management of the Remote DS-VDR service is performed on the DS-System using the DS-Operator. The DS-Client has no direct involvement with Remote DS-VDR. However, you must enable encryption key forwarding on the DS-Client to forward the encryption keys to the DS-System so they are stored in the DS-System database. For more information, see
“Configuring the encryption key settings”.
For each restore session, the DS-System provides the required encryption key(s) for the corresponding backup to the Remote DS-VDR service so it can handle multiple restore sessions from different DS-Clients. The encryption keys remain in encrypted format and are retained in temporary memory during each Remote DS-VDR restore and then discarded when the restore is completed.
For each Remote DS-VDR restore activity:
• The DS-System establishes the connection to the Remote DS-VDR service on port 4406 and sends the required configuration parameters, encryption keys, files, and other metadata information generated from the Remote DS-VDR configuration of the backup.
• The Remote DS-VDR service interacts with the virtualization server and creates a virtual machine and disks based on the metadata information.
• The Remote DS-VDR service decrypts and decompresses the data before saving it on disks to reduce the processing load on the DS-System.
• When manually triggering a Remote DS-VDR restore, you can select from the available backup generations stored on the DS-System.
• For VMware vCenter Server backups, the virtual machine is restored under a unique name that consists of the prefix “RVDR”, the name of the source virtual machine, and the backup session time stamp of the restored generation.
• For Microsoft Hyper-V Server backups, the virtual machine is restored with its original name. No time stamp is added.
• Depending on the Remote DS-VDR configuration, the restored virtual machine can be powered on or left powered off after a successful restore. If you select the Power On option, a full restore is always performed.
In the event of an actual disaster, the disaster copy virtual machine should only be manually powered on through the virtualization server. After it is powered on, the operating system present in the disaster copy will modify its disk and incremental virtual machine restores will no longer be possible after this point.
IMPORTANT: If you need to test the disaster copy, clone the disaster virtual machine to another location and use that copy for testing. If the disaster copy has already been used for testing purposes and a disaster occurs, the disaster copy might have already been altered during testing and is no longer be suitable as a disaster copy.