Once this issue occurs the recovery points taken after the upgrade are corrupted and unusable. The following steps must be taken to return the recovery point chain to a healthy state and continue using the SAN transport method:
- Stop the core service.
- Open up registry editor, navigate to HKEY_LOCAL_MACHINE\SOFTWARE\AppRecovery\Core\Agents{ESXi_Host_ID}\EsxServerProtectionSettings and set MaxConcurrentStreams to 1. (Note - the ESXi_Host_ID is the unique ID assigned by the core to the ESXi host or vCenter server that you connected to when protecting the agent. The simplest way to find this is to open the core console and browse to the ESXi host. The unique ID will be the 32 digit alpha-numeric code listed in the URL bar. It will follow the format XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX)
- Start the core service.
- Take new base images for any machines that are experiencing the issue.
- Delete any incremental backups that are corrupted (these would be ones that were created after the upgrade to 6.3.0 and before the base images taken in step 4 above.
To ensure the validity of your backups going forward it is highly recommended to enable the "Recovery Point Integrity Check" option in the nightly jobs settings of the core server.
If you are planning to upgrade to 6.3.0 and you use the SAN transport method, please do the following steps to avoid this issue:
- Pause all protection.
- Open up registry editor, navigate to HKEY_LOCAL_MACHINE\SOFTWARE\AppRecovery\Core\Agents{ESXi_Host_ID}\EsxServerProtectionSettings and set MaxConcurrentStreams to 1.
- Upgrade the core software.
- Validate that HKEY_LOCAL_MACHINE\SOFTWARE\AppRecovery\Core\Agents{ESXi_Host_ID}\EsxServerProtectionSettings\ConcurrentStreams is still set to 1.
- Resume protection.
This process will ensure no corrupt recovery points are taken, no new base images are needed, and the issue is completely avoided.