V13 backup to removable media retention issues

[bishoptf]

Running v13.1 software appliance and we created all new jobs migrating away from our v12 instance. One of those jobs is a backup to removable media that is rotated weekly. Pretty much set it up as how we had it running under v12 but starting getting emails about disk space and finally ran out of space even though retention was set for storage space. Looking at the directories where the backup reside it appears that it's not pruning or deleting the old jobs properly. The backup repo is a linux box and we have the option set for rotated drives and had the option for continuing backup chain if present but have changed that to delete backups belonging to this job.

Really not sure how to address the issue, on the console it states for one of the vm's that it has 1 restore point but when I look in the directory it has files for all of august. Can someone explain how retention and rotated drives is supposed to work and how I go about cleaning up the existing jobs when veeam console does not show the other restore points?

Thanks

[vnikiforov]

Hello, Tom,

The system is designed to work in the following way:

On a Linux repository with rotated drives, retention only covers the current backup chain. When the job detects a swapped drive it starts a new full and drops the previous chains from the configuration database. Their files stay on disk, as the Linux and Shared Folder section of the user guide describes. That is why the console shows one restore point while the folder still holds all of August. Background retention does not process repositories with rotated drives either, so with "Continue an existing backup chain if present" nothing removes the old chains and the drive fills up.

"Delete backups belonging to this job" fixes this. At the first job run after a swap, the job deletes its existing backups on the inserted drive and starts a new chain, per Deploying Backup Repositories with Rotated Drives. Each drive then holds only the chain written since it was last inserted.

The drive attached right now is cleaned the same way when it returns after the next swap. The issue is that already pre-existing old chains are no longer in the database, so the console cannot remove them, and rescan is not supported for repositories with rotated drives. Keep the VBM and the files created since the last swap, which match the restore point the console shows, and remove everything older manually.

That is by design, if there are some technical issues with the database or implementation and configuration, and system still does not follow the above workflow - that needs to be addressed with opening a support case.