NVP-vProxy: Backups Fail With 'Panic Occurred Runtime Error' When Data01 Is Full

Summary: NetWorker VMware Protection (NVP) vProxy backups fail with a "-500: Panic occurred: runtime error" when the /data01 partition on the vProxy appliance reaches 100% capacity. The /data01 partition stores backup session logs with a default retention of one month. When the partition is full, the vProxy cannot write session logs and the backup process panics. ...

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.

Symptoms

VM backups fail intermittently on a specific vProxy appliance. The NetWorker workflow log shows a 500 error with a panic runtime message:

MM/DD/YYYY HH:MM:SS [VM_NAME]: Unable to start backup on vProxy '[VPROXY_NAME]': Received an HTTP code: 500, libCURL message: "", vProxy message: "Error received from vProxy ="-500: Panic occurred: runtime error: invalid memory address or nil pointer dereference". ", url: "https://[VPROXY_NAME]:9090/api/v1/BackupVmSessions", body: "{"Config":{"SessionId":"","LogTag":"@(#) Build number: 288","IdleTimeout":300,"LogLevel":"TRACE","AcceptedLanguage":"en","TransportModeRequested":"hotadd","Parallelism":1,"UseCbt":true,"AutoEnableCbt":true,"AutoRepairCbt":true,"VimServerRef":{"HostName":"[VCENTER_NAME]","UserName":"S001891","UserPassword":"****","TcpPort":0},"VmSpec":{"Name":"[VM_NAME]","VmMoref":"vm-152712","VirtualDisks":[{"Label":"Hard disk 1","Key":2000}],"CustomFieldName":"Last EMC vProxy Backup","CustomFieldValue":"Backup Server=[NSR_NAME], Policy=[POLICY_NAME], Workflow=[WORKFLOW_NAME], Action=[ACTION_NAME], JobId=490597"},"SnapshotSpec":{"Name":"NetWorker Backup Snapshot","Description":"Snapshot is created as part of protecting this VM by EMC NetWorker VProxy.","Quiesce":false,"DumpMemory":false,"RemoveAll":false,"Consolidate":false},"TargetSpec":{"DeviceType":"DataDomain","HostName":"[DATADOMAIN_NAME]","UserName":"boostadmin","UserPassword":"****","BackupMode":"VSS","BackupPath":"[NSR_NAME]/[DEVICE_NAME]//[NSR_NAME]/[DEVICE_NAME]/05/47/e03a0faf-00000006-9122ca5e-5b22ca5e-5380e9f4-822ca7d4","PreviousBackupPath":"/[NSR_NAME]/[DEVICE_NAME]/75/82/7f12c16b-00000006-2720fcc2-5b20fcc2-40eae9f4-822ca7d4","CurrentBackupPath":"/[NSR_NAME]/[DEVICE_NAME]/active/e03a0faf-00000006-9122ca5e-5b22ca5e-5380e9f4-822ca7d4"}}}".

The /data01 filesystem on the vProxy appliance shows 100% utilization:

myvproxy:/data01/runtime/logs # df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda4 17G 2.7G 14G 18% /
devtmpfs 3.9G 8.0K 3.9G 1% /dev
tmpfs 3.9G 0 3.9G 0% /dev/shm
tmpfs 3.9G 8.8M 3.9G 1% /run
tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
/dev/sda4 17G 2.7G 14G 18% /.snapshots
/dev/sda4 17G 2.7G 14G 18% /var/crash
/dev/sda4 17G 2.7G 14G 18% /var/tmp
/dev/sda4 17G 2.7G 14G 18% /usr/local
/dev/sda4 17G 2.7G 14G 18% /var/spool
/dev/sda4 17G 2.7G 14G 18% /var/lib/pgsql
/dev/sda4 17G 2.7G 14G 18% /var/opt
/dev/sda4 17G 2.7G 14G 18% /var/lib/mailman
/dev/sda4 17G 2.7G 14G 18% /var/lib/named
/dev/sda4 17G 2.7G 14G 18% /srv
/dev/sda4 17G 2.7G 14G 18% /opt
/dev/sda4 17G 2.7G 14G 18% /home
/dev/sda4 17G 2.7G 14G 18% /tmp
/dev/sda4 17G 2.7G 14G 18% /var/log
/dev/sdb1 82G 82G 20K 100% /data01
/dev/sda2 95M 73M 18M 81% /boot
/dev/sda4 17G 2.7G 14G 18% /boot/grub2/x86_64-efi
/dev/sda4 17G 2.7G 14G 18% /boot/grub2/i386-pc
/dev/sdb2 16G 33M 16G 1% /data01/logs

The space is consumed by backup session logs in /opt/emc/vproxy/runtime/logs/. These logs reside on the /data01 partition. Other VMs on different vProxy appliances will continue to back up successfully.

Cause

The /data01 filesystem on the vProxy appliance stores backup session logs in /opt/emc/vproxy/runtime/. The default log retention is one month. In environments with high backup activity, the session logs can consume all available space on /data01.

When the partition reaches 100%, the vProxy cannot create new session log files. The backup process encounters a nil pointer dereference when it fails to write the log. This triggers a panic runtime error with HTTP status code 500.

Resolution

Option 1 — Redeploy the vProxy Appliance

Redeploy the vProxy appliance from the PPDM or NetWorker console. Redeployment clears all existing logs and restores the /data01 partition.

Note: The vProxy does not store data required for recovering existing backups. Redeployment does not affect recovery of previously backed up data.

Option 2 — Manually Reclaim Space

If redeployment is not immediately possible:

  1. Log in to the vProxy over SSH as admin. Switch to root:
    sudo su - root
  2. Delete old recycled session logs to reclaim space:
    find /opt/emc/vproxy/runtime/logs/recycle/ -type f -mtime +14 -delete
  3. Verify space has been reclaimed:
    df -h /data01
  4. Retry the backup for the affected VMs.


Prevent Recurrence — Configure a Log Cleanup Cron Job

To prevent /data01 from reaching 100% again, create a scheduled cleanup job:

  1. Log in to the vProxy over SSH as admin. Switch to root:
    sudo su - root
  2. Create a crontab entry for the root user:
    crontab -e
  3. Add the following line to delete session logs older than 14 days every day at 6 AM:
    0 6 * * * find /opt/emc/vproxy/runtime/logs/recycle/vbackupd -type f -mtime +14 -delete
  4. Save and exit the editor. Verify the cron job:
    crontab -l

 

Note: Adjust the retention period (number of days) as needed for the environment. A shorter retention keeps the filesystem from filling. A longer retention preserves more diagnostic logs.
Warning: The cron job is not preserved during a vProxy upgrade. After upgrading the vProxy, the cron job must be recreated.

Contact Dell Support

If /data01 continues to fill rapidly after implementing the cleanup, contact Dell Support for further investigation. Reference this KB article.

Article Properties
Article Number: 000033993
Article Type: Solution
Last Modified: 04 Sept 2026
Version:  5
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.