In some uncommon error scenarios (e.g., MSA unable to contact a DRVA) a failback task may become stuck and display a generic error message without an obvious meaning to the user. In such case, contact JetStream Software for assistance. (DRBC-4305)
While running a test failover runbook in manual mode, the runbook groups dialog box may show an empty group of independent protected VMs. This can be safely ignored. (DRBC-4694)
If the protected site goes down, the "Planned Failover" option will still appear in the GUI for all forms of failover. This option is only valid for “graceful” failover cases and will fail if planned failover is selected; however, the "Force Failover" option is appropriate and can be used successfully. (DRBC-5139)
If recovery fails or is cancelled and the MSA is unable to remove some representation VMs (RVMs), it might not automatically delete other related RVMs created for the same domain. Workaround: It is OK to manually delete all RVMs no longer needed. (DRBC-7178)
If a DRVA is restarted non-gracefully after failover or failback on the current site awaiting to start recovery, the resume continuous rehydration function may fail. (This is an uncommon occurrence.) (DRBC-7377)
If the source site is not properly cleaned up after a forced failover, it is possible the DRVA can become inaccessible requiring a hard reset. To avoid this, clean up by removing the policy from stale VMs and delete the stale protection domain from the DRVA. (JSDRAVS-187)
Continuous failover, test failover, and failback may incorrectly indicate “Invalid operation” after successful completion. This is a corner case and the actual process will have completed without errors. This error can be safely ignored. (DRBC-8156)
In some cases when there is no IO activity on a failover site with a total protected size less than 8GB, the regular failback operation may appear to hang indefinitely. A similar condition may also occur for continuous failback regardless of the total protected size. Workaround: Click the “Stop Remote site” button. (DRBC-8472)
Failback becomes stuck while taking ownership of the domain. This can happen when the domain on the primary site still exists and forced failover is performed. Workaround: Restart the DRVA, delete the domain and then re-run failback. Please contact support to perform required operations. (DRBC-8399)
It is advisable not to terminate the failback task after the domain ownership is transferred. If done so, the domain can enter a bad state. Workaround is to do a restore to the same site. (DRBC-8713)
If secure boot is enabled on a protected VM, the VM might not boot after a TFO with CFO. The workaround is to copy the .nvram file from this VM on the protected site to the TVM and boot. Regular recovery after CFO is expected to succeed. (DRBC-8667)
If there are more than 180 vDisks in a domain that has VMs protected in writeback mode, then any rehydration of the domain will switch the VMs to writethrough mode. (DRBC-8735)
If there is a RCR running on a site older than 4.3, then upgrading that site to 4.3 or later will lead to a wrong rehydration state. RCR should be completed before the upgrade. (DRBC-8738)