VMware backup failures with error code VMWARE42 due to Backup Proxy disk space exhaustion

Problem Description

VMware backup jobs fail unexpectedly with the error code VMWARE42. The Druva Management Console displays an error stating that the VMware backup proxy’s agent process terminated unexpectedly.

Cause

The backup proxy VM ran out of available disk space, causing the VMwarePartnerProcess to crash. This storage exhaustion is typically driven by an intentional scale-up of troubleshooting logs (e.g., debug logging explicitly set to level 9) that was not reverted after log collection, generating excessive write volumes over time.

Traceback

The following signatures can be found within the Backup job logs located at /var/log/Druva/EnterpriseWorkloads/vmware:

Plaintext

level=info ts=2026-06-17T11:47:49.167003566Z filename=logutil.go:306 dirPath=/var/log/Druva/EnterpriseWorkloads/vmware jobtype=backup backupsetid=XX jobid=XX

level=info ts=2026-06-17T11:47:49.168760465Z filename=logutil.go:316 message="Successfully compressed logs" jobtype=backup backupsetid=XX

level=info ts=2026-06-17T11:47:49.168935416Z filename=logutil.go:322 message="Successfully removed log file" jobtype=backup backupsetid=XX

level=info ts=2026-06-17T11:47:50.634981687Z filename=commandhandler.go:337 Executionfails,jobID=XX Module=CommandHandler method=postExecutionCallback error="exit status 2"

level=info ts=2026-06-17T11:47:50.63502583Z filename=commandhandler.go:360 Module=CommandHandler method=onPartnerProcessExit JobID=XX JobType=XX ExitStatus=2 PartnerPID=3576457 Traceback="VMwarePartnerProcess terminated with exit code 2: exit status 2" message="Partner process (PID 3576457) exited with exit code 2. Marking job as failed. Retry will be triggered only for scheduled jobs"

Resolution

Step 1: Resource Validation

Log in to your vSphere Client or monitoring suite to check for active CPU, RAM, or Datastore capacity alerts on the affected proxy VM.
Establish an SSH connection into the Druva VMware Proxy VM and evaluate real-time partition layouts and memory availability by executing:
```
df -h free -h
```
If any volume (specifically /var) shows 100% usage, clear old logs or temporarily expand disk space to allow services to start.

Step 2: Disable Verbose Debug Logging

If debug logging was previously enabled for an open support ticket, turn it back down to default limits:

Stop the Druva enterprise client service:

sudo service Druva-EnterpriseWorkloads stop

Open the primary configuration file using a text editor (such as vi or nano):
```
sudo vi /etc/Druva/EnterpriseWorkloads/Config.yaml
```
Locate debug_level: 9 and change it to:
```
debug_level: 0
```
Open the VMware-specific plugin configuration file:
```
sudo vi /etc/Druva/EnterpriseWorkloads/vmware/VMwareConfig.yaml
```
Locate debug_level: 9 and change it to:
```
debug_level: 0
```
Save both files and exit the text editor.

Step 3: Service Restart & Verification

Start the backup proxy agent client service back up:
Bash
```
sudo service Druva-EnterpriseWorkloads start
```
Trigger a manual backup job from the Druva console to verify that the VMWARE42 error has resolved and that disk utilization remains stable.