Problem description
VMware App-Aware processing for Transaction Log (T-Log) backup jobs fails and reports the exit code VMware24. The backup job generates the following error message:
Plaintext
VMware App Aware Processing: TL Backup did not upload any data [Skipped all TL backup in this attempt].
This issue can occur under the following distinct scenarios:
Scenario 1: All the user databases residing on the guest SQL server and targeted by the backup are configured in the Simple recovery model.
Scenario 2: The virtual machine does not host any active SQL Server instances, or the SQL Server service is not running entirely, despite Application-Aware Backup options being enabled.
Cause
For Scenario 1: Microsoft SQL Server does not support transaction log backups for databases utilizing the Simple recovery model. Since Druva cannot capture log entries from simple recovery databases, the log backup attempts are skipped.
For Scenario 2: The Druva backup policy has Application-Aware Backup options turned on for a virtual machine that either lacks a SQL server instance or currently runs a stopped SQL Server service. The guest plugin attempts to detect and back up SQL assets but finds no active engine to extract log data from.
Traceback
To determine the root cause, download the job logs from the Druva console, extract them, and navigate to the Phoenix-SQL-<YYYYMMDD>_<timestamp>_sqlguestplugin.log file.
Traceback indicators for Scenario 1 (Simple Recovery Model): Review the value of the _model parameter. A value of 3 indicates the database is in the Simple Recovery model, whereas a value of 1 signifies the Full recovery model.
Plaintext
[2020-03-18 10:38:00,641] [DEBUG] params of log name= [InstanceName][DBNAME] [2020-03-18 10:38:00,641] [DEBUG] Prev DB DETAILS {u'comp_level': 100, u'create_date': u'2019-06-27 12:22:05.657000', u'backup_start_time': u'2020-03-18 10:21:54', u'timestamp': u'CAAAAIKGdf7L/NUB', u'backupset_details': {...}, u'_model': 3 [2020-03-18 10:38:00,641] [DEBUG] LogBackupHelper: Inside __get_last_backup_type_from_metadata prev_db_details are present, getting backup type from prev_db_details, backup type D [2020-03-18 10:38:00,642] [INFO] Skipping log backup for simple recovery mode db or master db for any mode: INSTANCENAME, DBNAMETraceback indicators for Scenario 2 (SQL Server Not Active/Running):
Plaintext
[WARNING] VMware App Aware Processing: TL Backup did not upload any data [Skipped all TL backup in this attempt]. [ERROR] SQL Server instance is not accessible or service is stopped on the guest OS.
Resolution
Depending on your scenario, apply the corresponding resolution below:
Resolution for Scenario 1 (Databases in Simple Recovery Mode)
For T-Log backups to run successfully, the transaction logging chain must be enabled.
Connect to your SQL Server instance using SQL Server Management Studio (SSMS).
Right-click the affected database and select Properties.
Go to the Options page.
Change the Recovery model drop-down selection from Simple to Full.
Click OK.
Execute a fresh Full backup via Druva to re-establish the baseline log chain, after which subsequent scheduled T-Log jobs will complete successfully.
Resolution for Scenario 2 (SQL Server Is Not Running on the Virtual Machine)
If transaction log protection is not required because the virtual machine does not serve an active SQL workload:
Log in to the Druva Console and navigate to Protect > VMware.
Select your vCenter/ESXi host and go to Configured VMs.
Click the virtual machine experiencing the issue and identify its assigned Backup Policy.
Edit the assigned Backup Policy (or create a dedicated one for non-SQL workloads).
Under the Backup Schedule settings, clear or toggle off the Application-Aware Backup checkbox option.
Save the changes.
Trigger the backup job again. The system will now safely fall back to a standard crash-consistent VM backup and complete successfully.
Verification
To verify if the resolution worked:
For Scenario 1: Run a manual transaction log backup from the console after changing the recovery mode to Full. Confirm that the status switches to Successful and that the
Skipped all TL backupevent no longer appears in the job progress details.For Scenario 2: Verify that the job details view shows the backup executed strictly as a standard VMware snapshot/virtual disk backup without initiating the App-Aware Guest agent step.