Deleting performance tier backups

[Artaheri]

Hi, this is somewhat of a hypothetical that I am considering before we change our backup strategy. I haven't put in a ticket with support yet, but can if more appropriate; I figured it might be a quick answer here!

Take the following example:

Backup job to SOBR
Job retention 90 days
SOBR copy all backups to capacity tier
SOBR move all backups after 14 days

If I understand correctly, that would give 14 days of backups on the performance tier, and 90 days of backups on the capacity tier.

If we had an issue on the performance tier, for example running out of space on the backup server, and we needed to delete the backups on the performance tier to be able to run a new active full, would all the offloaded backups in the capacity tier remain? Or would deleting the backups on the performance tier delete everything on capacity, too? This would be running forward incremental with synthetic fulls weekly.

Thank you for any answers

[HannesK]

Hello,

If I understand correctly, that would give 14 days of backups on the performance tier, and 90 days of backups on the capacity tier.

almost correct, yes. You get minimum 14 days in performance tier. How many days it really will be depends on how often you do synthetic (or active) full backups. Because only inactive backup chains can be moved to capacity tier.

How would you delete backups in performance tier? Manual deletion is not recommended, because it brings the configuration database out of sync. If you delete "correctly" via "delete from disk", then everything is deleted in performance tier and capacity tier (there is a dedicated warning for that).

Best regards,
Hannes
PS: the forum is the right place to answer that type of question. Support is available to fix issues / errors. Not to explain how the software works.

[sfirmes]

As @HannesK noted, please don't manualy delete the files/backups from the performance tier (or any tier) from outside of the Veeam software. The "delete from disk" option from the VBR console is the preferred method.

[Artaheri]

Hi, thanks for the clarification on the 14 days, that makes sense.

I guess the "how" to delete is part of the question really. I always delete through the console to avoid errors as mentioned, but as far as I am aware—and as you say—this deletes everything in performance and capacity tiers.

Is there any way to delete backup chains in the performance tier, while keeping those in the capacity tier intact? By extension, if there was a failure with the hardware in the performance tier, would all backup chains be lost, including in the capacity tier?

[HannesK]

Hello,

Is there any way to delete backup chains in the performance tier, while keeping those in the capacity tier intact?

yes, by removing capacity tier from SOBR.

By extension, if there was a failure with the hardware in the performance tier, would all backup chains be lost, including in the capacity tier?

no. That would be render "copy" and 3-2-1 rule useless Data will be downloaded again from capacity tier to performance tier

Best regards,
Hannes.

[sfirmes]

@Artaheri as @HannesK noted, you can remove the capacity tier from the SOBR. Then delete the backup from the performance tier. If you need to restore the data from the capacity tier, you can add the capacity tier back to the sobr and Veeam will find the objects in the bucket. You can then import the backup into VBR and restore from the "Capacity Tier (Imported)" under the "Backups" section of the gui.

[Artaheri]

Thanks for the information, that makes sense. Just to confirm, the process would be:

• Remove capacity tier through SOBR properties > Capacity Tier > Uncheck "Extend scale-out backup repository..."

• Delete backups on the performance tier through Home > Backups > Disk

• Re-add capacity tier through SOBR properties > Capacity Tier > Check "Extend scale-out backup repository..." with the same settings as before

Then import, as @sfirmes outlined

[sfirmes]

@Artaheri you can follow those steps. You can also skip the 3rd step and just import the backups directly from the old capacity tier. Both methods accompish the same end result and enables you to restore from the old capacity tier.

[Artaheri]

Thanks Steve, we only use a single capacity tier in our SOBRs so would want to add it back in for future backups.

Thanks for everyone taking the time to respond, this has been very helpful.

[TheGrove]

Why not use the Override function on the Capacity Tier definition?

[jcavalear]

In reading through your scenario you say you're out of room on your performance tier to complete a new Full backup. Couldn't you just adjust your job settings to offload to capacity tier down to 7 days or something shorter to offload data from the performance tier to free up space? This would be dependent on how your backup jobs are configured with full and incremental backups. You'd have to be performing full backups each week to close the 7 day string of backups as the full backup is needed for the day 6 incremental to be valid.

I'm sure the Veeam engineers here could chime in if my reasoning is not correct here. Just trying to offer a potential alternative to deleting any backups to free up space.

[Artaheri]

jcavalear that's actually pretty much what I have done now that we are utilizing offloads more appropriately.

The issue we have had previously is where a large amount of block changes in a VM cause an incremental to be almost as big as an active full, so even with more regular offloads it can suddenly use up a lot of space. We use deduplication on a file server and sometimes that can cause a huge incremental even without a lot of changes at file level. When this has happened before we've effectively had to start again with a fresh active full and lose the chain. Now that we are keeping weekly and monthly backups on the capacity tier I was hoping to be able to avoid this (previously we were only copying backups to capacity tier, not keeping archived ones.)

[veremin]

We use deduplication on a file server and sometimes that can cause a huge incremental even without a lot of changes at file level.

This is expected, deduplication or antivirus process are known for causing a high number of changed blocks - a file might look the same, but it gets changed on the block level (think about Windows deduplication garbage collection, for instance, that regularly touches the files).

Thanks!

[Artaheri]

This is expected, deduplication or antivirus process are known for causing a high number of changed blocks - a file might look the same, but it gets changed on the block level (think about Windows deduplication garbage collection, for instance, that regularly touches the files).

Yup, we also offload some files to Azure using Azure File Sync, and again even if we actually free up some space at file level, the block changes for dedupe can be massive and cause a huge incremental.