- App aware T-Log backups fails with the VMware 27 error.
- Druva Phoenix tracks the LSN value of the transaction logs till the point it has been backed up.
- In the next attempt, Phoenix attempts to read the SQL Transaction Log on the Server and compares the LSN value.
- The LSN value picked up from the SQL should be the first LSN written from the moment of the last transaction log backup.
- The log chain should be consistent for all the Point-in-Time restore attempts made in the future to ensure consistent data.
This issue occurs if the log chain is broken.
- Obtain job logs using the instructions provided in the article.
- Extract the logs and go to Phoenix<YYYYMMDD>_<timestamp>.log file to view the below traceback in the logs.
[2020-03-13 15:49:43,965] [ERROR] Error <class 'inSyncLib.inSyncError.SyncError'>:Detected chain break for [DB_Name] (#10001001b) (Error Code : VMWARE27). Traceback -Traceback (most recent call last):
File "agents/vmware/appaware_sql_tl_backup_restore.py", line 383, in upload_trans_log_file
SyncError: Detected chain break for [DB_Name] (#10001001b) (Error Code : VMWARE27)[2020-03-13 15:49:43,965] [ERROR] Error in Uploading Log Files to Storage. : Detected chain break for [DB_Name] (#10001001b) (Error Code : VMWARE27)
[2020-03-13 15:49:44,019] [WARNING] Error occurred while taking SQL TL backup 4295032853 Detected chain break for [DB_Name] (#10001001b) (Error Code : VMWARE27): 10.80.30.24.
The VMware App aware feature has intelligence embedded that performs a full backup of the server automatically when T-Log backup fails. This resets the LSN value and the T-Log backups succeed.
It is recommended to verify if there are any backups from either using the SQL native tool or using a third party backup vendor product. If confirmed, disable the non-Druva Phoenix backup as that can cause the Log chain to break.