Out of Space maintenance and recovery Tasks


Additional troubleshooting if you are receiving “Out of Space” or “No More Purgeable Backups” errors in your backup failure reports


The following errors are displayed in backup failure reports:

  • Out of Space
  • No More Purgeable Backups

This article is a supplement to How to address "NO MORE SPACE ON DEVICE" and provides maintenance checks in addition to the troubleshooting and simple options presented in the prior article.

For more information on "Out of Space" conditions see Error: No more space on device


The following additional troubleshooting steps may be taken.  These steps are primarily routine maintenance in origin, and both can and should be performed on a routine basis to maintain optimal D2D storage availability for actively protected clients and applications.

1)   Check for Old or Outdated backups:  Over time, a backup system may have many clients register to it.  Over time you may decide to cease protecting old machines.  Many admins prefer to leave old clients registered in the product in case a recovery is required from archive, but they are no longer performing active protection of that client.  In other cases, a client may still be active, but some database or application resources have been migrated off that client.  In these cases, the last backup of each primary type for that client/application will never be naturally purged, no matter it’s age.

An admin can locate these backups easily in the backup System in one of 2 ways.  A) Settings > Storage and Retention > Retention will list the number of days between the current and oldest backup for each registered client.  If any client has retention beyond expectations, use the Backup Browser to identify those backups and remove them.  B) Delete a client using Settings > System IUpdates and Licencing > Clients, which will automatically remove all backups from the D2D for that client, then re-add the client to the DPU if you would like.

2)   Look for Duplicated scheduling in VM and Agent schedules:  If you have VMs that you are additionally performing file level backup operations for, the Backup System treats both the VM backups and Agent backups as if they are distinct clients.  This will cause the most recent (last) backups of BOTH schedules to be protected from purging, and in limited retention scenarios where de-duplication may not be operating, this can be a significant additional data load.  Best practice is to do either VM backups or agent backups of a machine, but not both.  The exception to this rule is under 7.0 systems using AppAware you can use VM backups for file level after excluding VSS writers from VMWare’s configuration and then use Application agent backups for the client databases for backup flexibility.  Under 6.4.1 and older systems, admins should use exclusively Agent backups OR VM but not both for the same guest.

In some cases, admins may have previously done Vm then changed to agent backups, or vice versa, and then neglected to manually purge the old backups for the no longer active backup type.  Use the steps in process 1 above to remove the redundant backups and make sure your backup schedules for VM/Hyper-V guests and Agent backups are not redundant in the future.


No Purgeable backups can happen when processes are utilizing space outside of the D2D device limiting the available space to the D2D, or because backups in the D2D that would be thought purgeable are prevented from deletion by a logical process.

Have more questions?

Contact us

Was this article helpful?
0 out of 0 found this helpful

Provide feedback for the Documentation team!

Browse this section