Immutable backups efficient retention (disk space wise)

[mriesenbeck]

Hi,

With V11 we have moved from Windows based repo's to Linux Hardened with immu.

Now, in the past things were quite easy, we had a backup job with retention of say 14 days going to local backup storage, then we had a backup copy linked to that backup job that would store 30 days worth of restore points to another DC on another storage. So in the backup copy a retention of 30 restore points was used.

With immu you need to configure on repo level the retention period that backups need to stay immutable, so 30 days/points (assuming one backup per day). BUT, in the backup copy job you are required to configure GFS, the shortest interval being 1 week.

Now, what I see in practice is that where in the old windows days the number of stored backup copy restore points was always 30. But since changing to immu the number increases over that 30. Is that because Veeam needs to wait until the next weekly full is made (on saturday in this case), so effectively you don't store 30 rp's but 36/37?

Would it be better in that case for me to calculate those 6/7 extra rp's in and set the repo immu period to 22/23 days in order to get back to 30 restorepoints?

The thing is that those extra rp's take up space, making volumes run out of space for volumes without a lot of extra spare space.

Thanks for any help!

[HannesK]

Hello,
Your thinking is correct so far.

The "better" depends how much free space you have. The GFS restore points are for free with XFS block cloning. So you just need to decide from the size of your restore points, whether it fits or not. If in doubt, I would start with 21 days immutability, 3 GFS weeks and 21 days retention (which would be up to 28 days then). Once everything is fine, add more retention days.

Best regards,
Hannes

[mriesenbeck]

Thank you!

Would changing the full synthetic from once per week to everyday free up those earlier rp's as well? So 30 immutability, 3 gfs weeks and 30 days retention? Would the outcome be the same, or does the frequency of fulls not impact the deletion behavior?

[HannesK]

hmm, backup copy jobs don't offer synthetic fulls every day. If that would be possible, then you could go with 30 days retention and it would apply retention on 31st day.

[mriesenbeck]

Correct, but for Backup Jobs it would be an option to switch from one week day to every weekday? I have a similar challenge for those customers, so that would be good to know.

[HannesK]

I think nobody ever tried that at scale, but as long as you don't run into filesystem issues ("too many references of cloned blocks"), that would work, yes. 30 days, daily synthetic full, no GFS.

[mriesenbeck]

I'm actually rolling out a project doing exactly this, so daily full incr, so after a week the 1st immu backups will be deleted, a day later the next immu backups, etc. So far no issues and the use of XFS makes the transforms a breeze.