Why backups are not pruned?

[decibel83]

Hi,

I configured the garbage collection as following:



All my backups from PVE are daily, so with this configuration I expect having 7 backups at maximum, but even after manually running the garbage collection I see this situation:



47 backups only for one VM is not what I expect.

When I manually run the garbage collection is seems to do the same work everytime:



And this is the situation from the dashboard:



Proxmox Backup Server is installed on a VM into PVE (this VM is not backed up into PBS), and the PBS storage is on an iSCSI volume on a Synology NAS.

Could you help me to understand what's going on, please?

Thank you very much!

Bye

 

[dcsapak]

can you post the task log of the last 'prune job'? should be under Administration -> tasks -> set type filter to 'prune'

 

[decibel83]

Thanks dcsapak for your answer!

Now the backups are pruned, perhaps the last prune did not run well:



But the datastore is almost full anyway:



Is there a way to understand how much data are physically occupied by each backup?
I know that this could be difficult due to the way PBS saves data (chunk based), but this would be interesting to understand what to keep and how many backups you could keep.

Do you prefer me to open a new thread for this?

Thank you very much!

 

[birdy]

Whats up with the "bad chunks"?

 

[decibel83]

Whats up with the "bad chunks"?

I really don't know.

The storage is on an iSCSI volume on a Synology NAS, so it should be safe and stable.

I understand that some chunks are not readable or available for some reason, but perhaps @dcsapak could explain us.

 

[dcsapak]

bad chunks are chunks that are either missing or corrupt... this would indicate some underlying storage/fs problem

The storage is on an iSCSI volume on a Synology NAS, so it should be safe and stable.

how did you mount it? whats the filesystem on top?

But the datastore is almost full anyway:

the actual chunks will only be deleted by a garbage collection 24h + 5min after the last access of that chunk

Is there a way to understand how much data are physically occupied by each backup?

no since the chunks are deduplicated across the whole datastore, there is no feasible way to count that
what we show is the 'raw' size the chunks have when restored (incl zero chunk)