Running out of space on backup device need to Prune but get error


Trying to prune on one of the vmware host but get this error:

~ # vertical prune -k 0:10

Vertical Backup 1.0.0
Storage set to sftp://user@

Collection 1 is eligible for deletion

Traceback (most recent call last):

File “”, line 141, in

File “”, line 819, in pruneCommand

File “”, line 1404, in prune

File “”, line 1563, in deleteFossils

File “”, line 316, in getSnapshotChunks

File “”, line 373, in downloadChunk

File “”, line 368, in decryptAESGCM


Failed to execute script vertical_main

The total size of backup is 2 TB on backup device. Need to prune b/c of running out of space but I’m getting these errors? How can I fix this? If prune doesn’t work how can I safely free up space?


@gchen let me know what I should do… need to free up space


You can run Duplicacy on any Windows/Mac/Linux machine to delete old backups.

First you need to create a dummy repository that connects to the same storage:

duplicacy init vm1@esxihost sftp://user@

‘esxihost’ should be the host name of one of your esxi hosts.

Then you can run the prune command to delete old backups:

duplicacy prune -a -keep 0:10

This prune command may not free up space immediately, since it only renames unreferenced chunks instead of deleting them according to the two-step fossil collection. However, if you’re sure no backup to the same storage is in progress, you can run it with the ‘-exclusive’ option to delete those chunks right away:

duplicacy prune -a -keep 0:10 -exclusive

If this prune command is set up to run regularly then the -exclusive option is not needed.

I guess once you start to limit the number of old backups to keep you should be able to run the prune command from your esxi hosts. And you just need to run it from one host if they are all connected to the same storage.

License wise, Duplicacy can be used freely to manage backups created by Vertical Backup, so no Duplicacy licenses are required.


Thanks that worked!


I am also getting this same error when using a prune. Is this expected behavior?


If I run the same command with a vertical.1.1.5 executable the command works. Is this a bug with 1.2.1?


1.2.1 is supposed to use less memory than 1.1.5 because a few optimizations done between these two versions, but generally speaking this is actually an out-of-memory error which is cause by the very low memory limit on processes running directly inside the ESXi host (less than 1GB no matter how much physical memory the host has). Therefore, it is recommended to use Duplicacy on a non-ESXi machine to run the prune job.