Retention on rotating drives

[Pixel11]

Hello all,

I'm quite sure this must've been asked before, but I haven't really found anything to fix the knot in my brain regarding this topic. It's probably entirely a problem of basic understanding.

We have a vSphere Host that already gets backed up to multiple NAS-targets, all fine.

We now added an offline solution in the form of multiple external HDDs.

Once a week, we run a dedicated active full backup onto those drives. They can technically hold four backups until they are completely full, but we don't want to go that far, the goal was to have two VBKs on each drive, eventually. So the retention is set to two restore points in the job.

The problem is that, currently, no previous files get deleted at all. I've ended up with full drives repeatedly, four VBKs on them and Veeam failing when trying to create a fifth without deleting anything.

I've read about the registry tweaks that are possible regarding rotating drives, but from how I understand it, that would likely delete everything on the drives, which isn't the goal either.

What am I doing wrong here?

[david.domask]

Hi Pixel11,

Welcome to the forums, I think I can help untangle this knot for you.

https://helpcenter.veeam.com/docs/backu ... ml?ver=120

Give this User Guide page a read as it covers the specifics on how the rotated drive will work; Primary Backups (Backup Jobs) and Backup Copies have slightly different handling, as do Repositories backed by rotated drives depending on the type of repository (Windows vs Linux/Network Share)

The registry tweaks if I remember right are no longer needed because previously the options the registry value enabled are now in the UI (step 2c)

Are you using a Windows or Linux/Network Share repository backed with rotated drives? The final step with Windows servers should apply retention, but with Linux/Network Shares, it uses the cropped retention mechanism mentioned in the link above.

[Pixel11]

Alright, thank you, that is indeed helpful.

The repository is an external HDD connected to a NAS. So for all intents and purposes, it's an SMB share. It's set up that way because the users in the off-site location responsible for swapping drives have access to where the NAS is, but not the server itself. The Veeam machine is also a VM itself and passthrough is a hot mess.

The article does indeed explain why it happens the way it does. The cropped mechanism just doesn't handle it the way we would need it to.

It doesn't really provide me with a solution for the way it's currently implemented, however.

I assume, if my understanding is correct, that the only way would be to swap the external drives from the NAS to the backup-server? Otherwise, I guess, some sort of script that deletes anything other than the two most recent .VBKs

[david.domask]

Hi Pixel11,

Glad the article helped explain this a bit away.

Indeed, regrettably with your setup, a bit of manual work will be required, but it should be easy enough to write some script that just collects the files in the backup path, sort by the creation time, then pass the two oldest VBKs to rm or Remove-Item.

Else, using a Windows server would indeed help here. Indeed I would avoid passthrough as well as past experience with it showed it at best unreliable, but it can be used if it's the only option.

[Pixel11]

Thanks for confirming that. A "proper" Windows Server is unfortunately no option, so yes, I put a script in for the job to execute, that should solve my issue with full drives.

The more you know! Cheers!

[david.domask]

Glad I could help untangle this a bit for you! Keep in mind, even a Windows workstation could be used if there's maybe an older server sitting around that could serve this purpose, but scripting you can implement today.

Good luck!