Enterprise Workloads Editions
❌ Business| ✅ Enterprise (Purchase Separately) | ✅ Elite

DR Failback Checks

Overview

A DR failback failbacks the AWS EC2 instances (created during DR failovers) to your VMware infrastructure. The DR failback checks preemptively identify issues with the AWS environment or your VMware environment that can cause your DR failbacks to fail. Fix any identified issues proactively and failback your VMs with confidence. You can run DR failback checks on-demand.

Prerequisites for running the DR Failback Checks

All the Druva AWS proxies and VMware backup proxies must be on version 6.0.1 or higher to run DR failback checks. See Upgrade Druva AWS proxy and Upgrade VMware backup proxy for details.

Additionally, the administrator account performing the DR failbacks must have all the rights required for Disaster Recovery management.

Accessing the DR Failback Checks

You can run DR failback checks on demand from the Failover Instances page of a DR plan.

Log in to the Management Console.
Select your organization if organizations are enabled.
On the menu bar at the top, click Disaster Recovery.
On the DR Plans page, click the DR Plan for whose VMs you want to run a failback check. Alternatively, select a DR Plan from the DR Plan drop-down.
In the left pane, click Failover Instances.
Select one or more EC2 instance IDs for which you want to run the failback checks, click Failback, and then select Run Failback Checks.
The failback checks use the same settings that you’d use in actual production failbacks. For more information, see Failback Settings. After entering the required EC2 and VMware settings, click Finish. This initiates the DR failback checks. If all checks are successful, you can review the check results and close the dialog box. If the DR failback checks identify any issues, you can follow the suggested remedial actions and then re-run the checks before attempting a DR failback.

Download the Failback Check results and debug logs

You can download a CSV file of all the executed failback checks. You can also download the debug logs associated with the executed failback checks. In the Checks tab of the Failback Checks dialog box, click Download > Export Checks to CSV to export the failback check results to a CSV file. Click Download > Download logs to download the debug logs.

The CSV file shows you all the checks performed, their status, and remedial actions, if any. It also shows you the failback settings used to run the checks. Clicking Download logs gives you the debug logs associated with the failback checks. You can share these with support should the checks fail for some reason.

DR Failback Check details

The following table describes the DR failback checks in detail and tells you how to resolve any identified issues with the DR failback.

Failback checks - Environmental

Check	Description
Checks the failover EC2 instance state and status	What is checked? We check if the AWS EC2 instance is running and the system status is OK. What if the check fails? The check fails when the AWS EC2 instance is in a stopped, stopping, terminated, pending, or shutting-down state. Ensure that the AWS EC2 instance is running and the system status returns 200 OK.
Checks the security groups attached to the failover EC2 instance	What is checked? We check if the security group attached to the failover EC2 instance has an inbound rule that allows ports 445 and 50000 for a Windows EC2 instance and an inbound rule that allows port 22 for a Linux EC2 instance. What if the check fails? Ensure that the security group attached to the failover EC2 instance has an inbound rule that allows ports 445 and 50000 if this is a Windows EC2 instance and port 22 if this is a Linux EC2 instance.
Checks the availability of the configured static IP	What is checked? We check if the static IP address defined in the failback settings is available or not. What if the check fails? Enter an alternate static IP address that is available and rerun the failback check.
Checks the configuration status of the static IP	What is checked? We check if the static IP address and the gateway are in the same subnet or not. We also check the subnet netmask of the static IP address. What if the check fails? Ensure that the static IP address and the gateway are in the subnet and that the netmask for this subnet is not /32.
Checks for the presence of destination VMware resources	What is checked? We check if the compute resource, VM folder, and the network specified in the failback settings exist or not. What if the check fails? Ensure that the destination ESXi host is reachable. Ensure that the resource pool where the VM should be created is accessible. Ensure that the VM folder where the VM should be created exists. Ensure that the network specified in the destination VMware Settings exists.
Checks if the failback VM image is accessible from the VMware backup proxy	What is checked? We check if the failback VM image URL is accessible from the VMware backup proxy or not. Failback VM image is the image used to create the failback VM. The VMware backup proxy downloads this image from downloads.druva.com. What if the check fails? Check if the failback VM image URL is inaccessible from the VMware backup proxy because of network or firewall issues. Check if the failback VM image URL returns an HTTP status code 200 OK or not. The following example demonstrates how to use the failback VM image URL returned in the error code and check if it returns status code 200 or not. Use the image URL in your error message. The following is an example: `phoenix % wget --method HEAD` `Spider mode enabled. Check if remote file exists.` `--2022-02-08 14:42:12--` `Resolving downloads.druva.com (downloads.druva.com)... 34.197.15.99, 34.206.32.193` `Connecting to downloads.druva.com (downloads.druva.com)\|34.197.15.99\|:443... connected.` `HTTP request sent, awaiting response... 200 OK` `Length: 1258291200 (1.2G) [application/x-virtualbox-vmdk]` `Remote file exists.` Check if the failback VM image URL is valid or not.
Checks if the selected Datastore has sufficient free space	What is checked? We check if the Datastore selected in the Destination VMware Settings has sufficient free disk space to store the failback VMs of all the selected failover EC2 instances or not. What if the check ends with a warning? The selected Datastore may only have space to accommodate the failback VM of a specified failback EC2 instance but may not have space for the failback VMs of the other failover EC2 instances. What if the check fails? The check may fail if the selected Datastore does not have space to accommodate any of the failover VMs of the selected failover EC2 instances. Select an alternate Datastore with sufficient free disk space for all the failback VMs for all the failover EC2 instances.
Checks if the selected network is non-isolated	What is checked? An isolated network is a network that can communicate internally but not with the external world. We check if the network selected in the Destination VMware Settings can communicate with the EC2 instance or not. In other words, whether this network is non-isolated or not. For a successful failback, this network must be non-isolated. What if the check fails? The checks may fail because of one of the following reasons: The vSwitch may be isolated because no physical adapter is connected to it. The network may be isolated because its physical adapter is in a down state. The network may be isolated because no vSwitch is connected to the network.
Checks if firmware used for failback is BIOS	What is checked? We check if the source VM uses BIOS firmware or not. The DR failback will create a VM with BIOS firmware if the source VM's firmware is UEFI, and if you have not upgraded your AWS and backup proxies to version 6.3.1 or later. What if the check ends with a warning? The check ends with a warning if The source VM has the UEFI firmware You have VMware and AWS proxy versions lower than 6.3.1 You select the Use Source VM Attributes option in the Destination VMware Settings. The failover EC2 instance will be failed back, however, the failback VM will use the BIOS firmware.
Checks if VM with same name already exists on the Datastore	What is checked? We check if a VM with the name specified in the failback settings already exists on the selected Datastore or not. What if the check ends with a warning? The check ends with a warning when we find a VM with the same name on the selected Datastore. The failover EC2 instance will be failed back, however, it will be assigned the name <Virtual Machine Name>_suffix. For example, if the VM name specified in the failback settings is `PRD_Win_VM` and another VM with the same name exists in the selected Datastore, we will failback the VM with the name `PRD_Win_VM_1`.
Checks if the VMware hardware version is compatible with ESXi version	What is checked? We check if the VMware hardware version of the source VM is compatible with the selected Hypervisor's ESXi version. What if the check ends with a warning? The check ends in a warning when the hardware version is incompatible with the ESXi version. The DR Failback will complete with a warning and the failover EC2 instance will be failed back to the next supported hardware version. What if the check fails? The check fails when the DR failback cannot fail the EC2 instance over to the next compatible hardware version. To ensure a successful DR failback, select a hypervisor that is compatible with the source VM’s hardware version.
VMware to AWS connectivity checks
Checks if connectivity to Failover EC2 Instance is established	What is checked? We check if the failover EC2 instance is reachable from the VMware backup proxy or not. What if the check ends with a warning? The check ends in a warning if the network associated with the VMware backup proxy cannot reach the failover EC2 instance.
Checks if the SSH is accessible on the Failover EC2 instance	What is checked We check if the VMware backup proxy can access the failover EC2 instance via SSH or not. What if the check fails? The check fails if SSH is disabled on the failover EC2 instance.
Checks if the Failover EC2 Instance Credentials are valid	What is checked? We check if the specified credentials of the failover EC2 instance are valid or not. What if the check fails? The check fails when the specified username or password of the failover EC2 instance is incorrect. The check can also fail if you've entered domain administrator credentials, but the failover EC2 instance is not joined to the specified domain controller.
Checks if the SMB is accessible on the Failover EC2 instance	What is checked? We check if SMB shares are accessible from the failover EC2 instance or not. What if the check fails? Ensure that port 445 and port 50000 are allowed in the inbound rules of the security group attached to the failover EC2 instance. To verify the access to SMB shares, run the `<ip-of-ec2>/Admin$` command from the Windows > Run box on any Windows computer. If the access is denied, perform the following steps on the failover EC2 instance: Ensure that the security group associated with the EC2 instance allows ports 445 and 50000 in the inbound rules. All ports must be allowed in the outbound rules. Enable rules for port 445 and port 50000: Login to the EC2 instance as an Administrator. Open the Windows Firewall with Advanced Security console. Go to Inbound Rules. Open the port 445 and port 50000. Select the rule and click Enable Rule. If there is an on-premise network firewall, then whitelist port 445 and 50000 over the on-premise network firewall from the vCenter network to the failover instance.

Failback checks - Guest OS

Linux Failback checks

Check	Description
Checks that all required metadata was collected from the source.	What is checked? We check if all the required metadata was collected from the failover EC2 instance or not by executing necessary commands inside the Guest OS. What can the check fail with? Target OS customization error. Unable to identify partition using the `parted` command. What if the check fails? This is a generic Linux customization error. Download the logs from the Job Details page. If the check failed because it couldn't parse the output of the `parted` command, then on the source VM, run `parted` command. If no output or incorrect output is generated, fix the issue with `parted` and rerun backup. Sample output `(parted) print` `Model: VMware Virtual disk (scsi)` `Disk /dev/sda: 42.9GB` `Sector size (logical/physical): 512B/512B` `Partition Table: msdos` `Disk Flags:` `Number Start End Size Type File system Flags` `1 1049kB 30.9GB 30.9GB primary ext4 boot` `2 30.9GB 42.9GB 12.0GB primary linux-swap(v1)`
Checks there is enough free storage space.	What is checked? We check if the amount of free storage space is sufficient or not. What if the check fails? The check may fail if the source does not have enough free space on `{MPOINT} ({DEVICE})`. At least `{<SIZE>}` Mb space is required․ Provision additional free disk space as described in the message.
Checks the source boot loader is supported.	What is checked? We check if the source boot loader is supported or not. What if the check fails? The check may fail if the source has an unsupported version of GRUB. Install grub-legacy or grub2 on the source and try again․ Ensure that grub-legacy or grub2 is installed on the source virtual machine. Else, install the grub package on the source virtual machine. Review the GRUB installation documentation for your operating system. For example for CentOS refer to: https://wiki.centos.org/HowTos/GrubInstallation.
Checks the source operating system is supported.	What is checked? We check if the source operating system is supported or not. What can the check fail with? This OS is not supported. Please review our documentation for supported OS for conversion․ What if the checks fails? Review the system requirements.
Checks cloud-init configuration for potential problems.	What is checked? We check the `cloud-init` configuration for potential problems. What can the check fail with? SSH pwauth is disabled in the `cloud_init` file. If you proceed, you might not be able to login to the target instance or VM․ Lock password is enabled in the `cloud_init` file. If you proceed, you might not be able to login to the target instance or VM․ What if the check fails? `Cloud-init` is installed on the EC2 instance and it has configurations that have disabled SSH password authentication. Ensure that SSH password authentication is allowed. `Cloud-init` is installed on the EC2 instance and it has configurations that can lock the account's password. Disable Lock password in the `cloud_init` file.
Verifies source filesystems are supported.	What is checked? We check if the source filesystems are supported. What can the check fail with? {DEVICE} has {FS_TYPE} filesystem, which is not supported. What if the check fails? One of the devices has an unsupported file system. Failback can continue if it is excluded. For failback, this means the file system might be missing from the target. See, Configure virtual machines for backup. Ensure that the disk to be excluded does not have following mountpoints : "/", "/usr", "/var" ,"/boot"
Selected Disks	What is checked? We check if failback can proceed with only the selected disks. What can the check fail with? {MOUNT} is not one of the supported mounts. Mount {MOUNT_POINT} won't be available on the target as disk {DISK} was skipped. Mount {MOUNT_POINT} won't be available on the target as some of the PVs of the Volume Group is on skipped disks: {DISKS}. Disk {DISK} isn't used by any file system. What if the check fails? An unknown/unsupported mount point was listed in selected_mounts. Make sure selected_mounts is a subset of supported_mounts returned from Failover checks - Guest OS. If the skipped volume is critical, add the skipped disk to selected_disks. Can be ignored otherwise. If the skipped volume is critical, add the skipped disk to selected_disks. Can be ignored otherwise. Consider removing the disk from the backup and selected_disks.
Checks source LVM volumes are of supported type.	What is checked? We check if LVM physical volumes are on supported storage devices. What can the check fail with? Device {DEVICE} which is a PV for LVM Volume Group {VOLUME_GROUP} (mount: {MOUNT}) was not recognized as a supported device. What if the check fails? The block device which holds the volume was not recognized as a supported device. Failback can't continue if the volume is critical. 📝 Note Bind-mount is also not a supported device.
Checks whether we were able to detect the type of XEN hypervisor (does nothing for non-XEN).	What is checked? We check if the type of XEN hypervisor can be detected (does nothing for non-XEN). What can the check fail with? The check fails when we cannot determine if this xen-based source is an AWS EC2 instance, as instance metadata could not be retrieved. What if the check fails? Couldn't reach the AWS metadata service to determine this is an AWS instance. The instance ID will be missing. Verify if network settings are correct on ec2-instance. Verify if " `http://169.254.169.254/latest/meta-data/`" is reachable from the instance. To verify, launch a temporary EC2 instance with the same configuration as the Failback instance. If the metadata URL is not reachable from the temporary EC2 instance as well, refer to the AWS documentation for more information.
Checks the source DHCP config for unsupported options.	What is checked? We check the source DHCP config for unsupported options. What can the check fail with? DHCP configuration contains 'supersede'. Target might have a broken network. What if the check fails? The EC2 instance has custom DHCP client configurations. Druva doesn't reset the configurations. This could potentially cause issues. Verify the `/etc/dhcp/dhclient.conf` of the EC2 instance.
Checks the required mountpoints were recognized.	What is checked? We check if the required mount points were recognized. What can the check fail with? `/mountpoint` is mandatory. What if the check fails? Ensure that the VMDK containing " `/` " `mountpoint` is not excluded from backup.
Checks if user has enough permissions	What is checked ? We check if the provided user credentials has sufficient permissions to run Failback. What can the check fail with ? - WARNING `- User {USER} has no enough permissions. Permissions must be '(ALL) NOPASSWD: ALL'. {USER} permissions are {PERMISSIONS}` What if the check fails ? If the provided user credential does not have root-level permissions, then this check will fail.
Checks VMToolsd can be installed on the source (the dependencies are available).	What is checked ? We check if we can install `VMtoolsd` on the source or not. What can the check fail with ? - WARNING `Perl or Ifconfig are not installed on source. Vmware tools installation requires perl and ifconfig. Please install dependencies on source and try again. Missing dependencies: {PROGRAMS}` What if the checks fails ? We recommend installing perl/ifconfig and other missing dependencies on the failover EC2 instance.
Checks the source has either `tar` or `rsync` installed.	What is checked ? We check if tar or rsync is installed on the failover EC2 instance or not. What can the check fail with ? - BLOCKER `Neith tar nor rsync is available no the source.` `SFTP subsystem needs to be enabled in sshd config if rsync isn't available.` What if the checks fails? Install `rsync` on the EC2 instance (and on the original VM, so that the next failover EC2 instance will already have it installed). Druva will not allow a DR failback until this error is fixed. This is flagged as a warning in DR failovers. When using `tar` for the data transfer, SFTP subsystem must be enabled on the EC2 instance. See sshd documentation.
Checks the source sudoers requiretty status (only needed for non-root user).	What is checked ? For non-root users, we check the `sudoers` file on the source failover EC2 instance for the status of `requiretty`. `Requiretty` must be disabled. What can the check fail with ? - BLOCKER `sudo` is configured to require a `tty`. This is generally enforced by having ' `Defaults requiretty` ' in `/etc/sudoers`. Disable the `requiretty` setting. What if the checks fails ? Data transfer is impossible for non-root users for whom `requiretty` is enabled. Edit `etc/sudoers` so that non-root users can run `sudo` without `tty`. Druva does not allow a DR failback if `requiretty` is enabled. This is flagged as a warning for DR failovers.
Checks source disks partition tables are of supported formats.	What is checked ? We check if the partition tables of source disks are formatted in a supported format or not. What if the check ends with a warning? `The partition table of the disk was not recognized. It won't be transferred during failback. Can be ignored if the disk is not partitioned at all.` If you proceed with the DR failback despite the warning, the failback may be marked Successful with errors because the disks with the unrecognizable partition table format were not transferred.
Checks if lastlog or failog size more than 100MB	What is checked ? We check the size of logs at the location `/var/log/lastlog` or `/var/log/faillog` What can the check fail with ? - WARNING `The size of the /var/log/lastlog or /var/log/faillog file is more than 100Mb and it will be excluded during Failback data transfer.` What if the checks fails ? Delete logs that are greater than 100MB from `/var/log/lastlog` or `/var/log/faillog`. Alternatively, delete all logs from these locations.
Checks that RTC mode is UTC	What is checked ? We check whether the mode of Real-Time Clock (RTC) is set to UTC. What can the check fail with ? - WARNING `Either RTC mode is not UTC or we have failed to determine RTC mode. Determined RTC mode is '{MODE}'. Error msg is: '{ERR_MSG}'.` What if the checks fails ? We recommend to set the mode of Real-Time Clock to UTC using following command `timedatectl set-local-rtc 0`
Checks the required mountpoints were recognized	What is checked? We check if the required mountpoints are excluded. What can the check fail with? The check fails if the Failover EC2 Instance does not have the mountpoints configured in the Failback settings. What if the check fails? Select a mountpoint that exists in the Failover EC2 Instance.

Windows Failback checks

Check	Description
Checks the source is not a Hyper-V host	What is checked? We check if the source is a Hyper-V host or not. What can the check fail with? The check fails when the source is running Hyper-V. Migration of Hyper-V servers is not supported by Druva. Hyper-V servers will not be able to run in the target cloud and the source will fail to start in the target cloud environment. What if the check fails? Hyper-V is not supported.
Checks the source operating system is supported	What is checked? We check if the source operating system is supported or not. What can the check fail with? This OS is not supported for conversion. Please review our documentation for the OS we support for conversion. What if the check fails? Review the system requirements.
PV Drivers	What is checked? We check if the source has 'AWS PV Network Device' NICs or not. What can the check fail with? TCP offloading must be disabled on source with driver type {DRIVER}. What if the check fails? If phase 2 system has no network, disable TCP offloading on the source. To disable TCP offloading: In the Microsoft® Windows server, open the Control Panel. Select Network and Internet > Network and Sharing Center > Change Adapter Settings. Right-click on each of the private and public adapters, select Configure from the Networking menu, and click the Advanced tab. The window displays the TCP offload settings for the Citrix adapter. Select each of the following TCP offload options, changing the value to Disabled, and click OK: IPv4 Checksum Offload Large Receive Offload Large Send Offload TCP Checksum Offload
Checks there are no Windows Updates scheduled to happen on reboot.	What is checked? We check if there are pending Windows updates scheduled to happen after the Windows server reboot. What can the check fail with? Source has pending Windows updates detected. What if the check fails? Druva triggers a DR replication job (as per the replication frequency in the DR plan) even if the Failover Checks - Guest OS detect pending MS Windows updates. The DR replication job completes successfully; however, DR Failbacks from this DR copy may take longer than usual as Druva reboots the machines as part of the pending Windows updates. We recommend you apply the pending Windows updates and reboot your machines at the earliest opportunity so that the next DR replication job will create a DR copy that you can successfully Failback from within the expected duration.
Pending MS Windows chkdsk operation on the boot disk	What is checked? We check if there are pending chkdsk operations scheduled to happen after a Windows server reboot. What can the check fail with? Source has pending chkdsk detected. What if the check fails? Druva triggers a DR replication job (as per the replication frequency in the DR plan) even if the Failover Checks - Guest OS detect scheduled chkdsk operations on the boot disk. The DR replication job completes; however, DR Failbacks from this DR copy may take longer than usual as Druva tries to bypass the pending chkdsk operation on the boot disk. We recommend you complete pending chkdsk operations at the earliest so that subsequent DR replication jobs create a DR copy you can successfully Failback from within the expected duration.
Network Drivers	What is checked? We check if compatible NIC drivers are installed or not. What can the check fail with? Citrix PV Ethernet Adapter is not supported during AWS conversion. What if the check fails? The Citrix driver installed on the source might cause problems in phase 2. Uninstall the driver.
.Net	What is checked? Checks whether the required version of .Net Framework is installed. What can the check fail with? Microsoft .NET Framework v{VERSION} will be installed. What if the check fails? This is an information message. It can be ignored.
Checks source filesystems are supported.	What is checked? We check if the source file systems are supported. What can the check fail with? The source has unsupported file systems '{FS_TYPE}' (volume {VOLUME_ID}, mount point {MOUNT_POINT}). Volumes with a non-supported file system can not be transferred. What if the check fails? One of the devices has an unsupported file system . Failback can continue if it is excluded. See, Configure virtual machines for backup. Ensure that the disk to be excluded does not have following mountpoints : "C:"
Verifies previous Sysprep run wasn't incomplete	What is checked? We check if the previous Sysprep run wasn't incomplete. What can the check fail with? Druva has discovered that a previous `Sysprep` attempt did not complete properly on the source VM. In the registry navigate to ' 'HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session Manager\\ '' and locate the key '' BootExecute ''. Remove the line containing s `ysprepDecryptor.exe` and reboot the source VM before migrating. What if the check fails? In the registry navigate to HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session Manager\\ and locate the key BootExecute. Remove the line containing `sysprepDecryptor.exe` and reboot the source VM before migrating.
Checks whether the source is a Domain Controller.	What is checked? We check if the source VM is a Domain Controller. What can the check fail with? The source VM is probably a Domain Controller. What if the check fails? Domain controllers sometimes are slow to boot (might cause time outs) and are generally more prone to errors during Failback. Use larger instance-type like m4.xlarge family for running Failback.
Checks there is enough free storage space.	What is checked? We check if the free storage space is adequate or not. What can the check fail with? `The source VM doesn't have sufficient space on the C volume. Druva requires {TOTAL_SPACE_REQUIREMENT} MB free space on C volume.` What if the check fails? Provision additional free disk space on the volume specified in the message.
Checks whether the source has AV/protection software installed	What is checked? We check for the presence of anti-virus protection software on the source failover EC2 instance. What can the check fail with? `{AV_NAME} antivirus software detected (service name: {SERVICE_NAME}). If Failback fails, try whitelisting Druva software components.` What if the check fails? Antivirus software block `cli.exe` or other Druva executables during a DR failback. Whitelist the executables and retry the DR failback checks.
Selected Disks	What is checked? We check if the DR failback can proceed with only the selected disks. What can the check fail with? `Volume {MOUNT_POINT} won't be available on the target as disk {DISK} was skipped.` `Disk {DISK} isn't used by any file system.` What if the check fails? Consider removing the disk from backup and selected_disks. See, Configure virtual machines for backup. Ensure that the disk to be excluded does not have following mountpoints : " C:"
Checks the source TCP port 50000 is available.	What is checked ? We check if TCP Port 50000 is open/available in the failover EC2 instance so that we can perform failback data transfer using this port. What if the the check completes with a warning? `Another process is using TCP port 50000. This migration cannot proceed.` What if the check fails? Ensure that TCP Port 50000 is not used by any other process and that it is open on the failover EC2 instance.
Checks there is enough shadow copy storage.	What is checked ? We check if sufficient VSS Shadow Copy Storage space is available on the failover EC2 instance. What if the the check completes with a warning? `It appears that Shadow Copy Storage space is limited on volume(s) {VOLUMES}. This may cause migration failure if the rate of changes on the volume would exceed transfer rate. Consider changing Source Shadow Copy storage space.` What if the check fails? Ensure that more than 1GB free space is available on the volume mentioned in the error message for a successful DR failback.
Checks source isn't using Storage Spaces.	What is checked ? We check if the failover EC2 instance contains Storage Spaces. Storage Spaces are not supported. What can the check fail with ? `The source has Storage Spaces (disk id: {DISK_ID}), which is not supported` What if the check fails ? Remove Storage Spaces from the Failover EC2 Instance before attempting a DR failback. Druva does not allow a DR failback until this is fixed.
Checks the Source image has successfully been installed.	What is checked ? We check the Windows registry in the failover EC2 Instance for image state. What can the check fail with ? - BLOCKER `The Image State is {IMAGE_STATE}. Image could be undeployable.` What if the check fails ? Use a failover EC2 Instance whose image state is not IMAGE_STATE_UNDEPLOYABLE
Checks that user had enough permissions during attribute collection.	What is checked ? We check if the entered user credentials have sufficient permissions to run DR failback or not. What can the check fail with ? - BLOCKER The check fails if the credentials do not have administrator-level permissions. What if the check fails ? Ensure the user has unrestricted administrator rights. Ensure that UAC is disabled or its security level allows execution with full administrator rights without approval. For Windows Server 2012 and later, verify that the 'User Account Control: Run all administrators in Admin Approval Mode' security policy is disabled.
Checks that source has not x86 architecture	What is checked ? We check the OS architecture of the failover EC2 instance to determine if it is 32-bit or 64-bit. What if the check fails ? - BLOCKER The check fails if the failover EC2 instance has a 32-bit OS architecture. You can't initiate DR failback jobs for 32-bit failover EC2 instances. You can only initiate DR failback jobs for 64-bit failover EC2 instances. You may see the following error when the check fails: `Source OS Architecture. Detected unsupported OS architecture 'x86', only 'x64' OS architecture is supported.`
Checks whether the instance is domain joined	What is checked? We check if the Failover EC2 Instance is joined to the Domain-Controller. What can the check fail with ? The check fails when the Failover EC2 Instance is connected to the Domain Controller and the Stop EC2 after failback checkbox in thefailback settings is not selected because the computer-name collision can occur between the Failover EC2 Instance and the Failback VM. What if the check fails? We recommend selecting the Stop EC2 after failback option for stopping the EC2 Instance after failback so that there is no collision between the computer-name of Failover EC2 Instance and that of Failback VM.
Checks the required mountpoints were recognized	What is checked? We check if the required mountpoints are present and if they can be excluded. What can the check fail with? The check fails if the mountpoints configured in the Failback settings for exclusion are either not present in the Failover Instance or are required for successful boot process. What if the check fails? Select a mountpoint that exists in the Failover EC2 Instance. Make sure you select only those mountpoints which are not important for the boot process, for example, C:or /boot.
Checks the installed service status	What is checked? We check if the VSS and WMI Service is installed and is running in the Failover EC2 Instance What can the check fail with? The check fails if either the VSS and WMI service is not installed or is installed but not running in the Failover EC2 Instance. What if the check fails? Ensure that the VSS and WMI Service is installed and is running for a successful Failback.

About UEFI firmware support for Failover and Failback

Disaster recovery ports and communication protocols

About disaster recovery failback for VMware virtual machines

Manage disaster recovery failback

Disaster recovery errors