Entering a PITR recovery session requires the Domain to be in a consistent state (remaining background data = 0, current RPO close to 0 seconds). If the user initiates a PITR session while the Domain is not in a consistent state, the system will wait for the Domain to become consistent before starting the PITR session, causing delayed response to the user.
If a PITR recovery session is started in order to manage a subset of VMs contained in the Protected Domain, do not keep the PITR recovery session open longer than necessary. JetStream DR does not maintain consistency status of VMs not undergoing PITR. Best Practice: Create a new PITR-enabled Protected Domain that exclusively contains VMs intended to be managed by PITR.
The PITR window will be reset if the Domain is restarted. This can lead to extra object cloud and metaspace usage by the Domain.
PITR supports rollback of data in vDisks. It does not rollback VM configuration changes that occur across the PITR window. VM configuration changes discarded because of PITR should be replayed after the PITR session has been completed (e.g., VM configuration changes including: disk add, remove, detach and disk grow.)
While PITR is in progress, the Health View tab will show some of the protected disks as orphaned disks. This condition is transient and the disks will move to an initialized state after PITR is exited. This issue will be addressed in future releases. (JSTOOLS366)
It is recommended to enable PITR mode on a Protected Domain before adding VMs to the Domain, or to add a new VM to the Domain after PITR mode has been enabled. If a Domain is fully configured and then PITR mode is enabled without any changes to VMs, there may be problems with data collection. The workaround is to confirm PITR is able to successfully gather data by validating a recovery point exists after starting PITR recovery for any VM in the Domain – actual recovery is not required, but the selected VM will be temporarily shut down for the test. If there are no valid recovery points, the DRVA should be restarted after exiting PITR. (DRBC8047)
There is a rare chance the PITR recovery task can fail with a message "An unexpected error occurred on the remote system" with a distinction of "Unsupported or unrecognized SSL message." The condition is transient and should resolve itself after a period of time. It is OK to retry the operation after waiting. (DRBC5902)
In rare situations, a banner indicating "RVM IP has not been assigned" is displayed even after PITR recovery completes. This banner can be safely ignored. (DRBC8804)
Replication Log metaspace that was allocated for PITR doesn't shrink after disabling PITR. (DRBC8836)
Under some conditions after a PITR session, protected VMs may end up with unconsolidated disks. The workaround is to manually consolidate the affected disks. (DRBC8406)
After failover or failback of a protected VM, if there is a snapshot or a VMDK chain on the VM, then PITR recovery fails with error "Failed to create Representation VM". Workaround is to delete the snapshot/VMDK chain and retry PITR recovery. (DRBC9436)
During PITR recovery, an inadvertent reboot of the DRVA can occasionally lead to failure of any subsequent PITR recoveries. This is due to the inability to create snapshots on the VM(s) being recovered. The error message will indicate 'Failed to create PITR test VM(s). An error occurred while taking a snapshot'. Workaround is the following: (DRBC9544)
Temporarily power on the VM(s) being recovered.
Check whether snapshot consolidation is pending on the VM(s).
Create a snapshot and delete it to verify the snapshots are going through.
Power off the VM(s).
Continue with PIT recovery.
Starting CFO on a PITR domain fails if there is not enough space on the remote site replication log. Increase the replication log size and retry CFO. (DRBC9556)