Long Term Monthly/Yearly Retention On Object Storage

[BigChungus]

We have some on prem object storage that we would like to use for archiving monthly and yearly full backups. Our hope would be that the monthly full backups would be retained for 12 months and the yearly's would have to be kept for 5 years. Given my understanding of SOBR and capacity tier it doesn't seem this can be accomplished in a granular fashion or at all really. If I try use my daily backup policy to accomplish this I'm not going to be able to phase out all the retention points except for the monthly and yearly's as well as set individual retention policies on the monthly and yearly's. Seems as though it's either an all or nothing first in first out retention scheme.

Also wondering if setting up individual monthly and yearly backup policies might work... and staging the data in performance tier for a day prior to being offloaded to capacity tier then just set the retention points for 12 (months) and 5 (years) respectively for each.

I've looked into the copy mode functionality in v10 and it doesn't seem like this is the answer for our aforementioned situation either.

Thanks!

[wishr]

Hi BigChungus,

Please let us know what kind of on-prem object storage it is. The use-case you described is covered in v10, but you'll need a SOBR with Copy Mode activated to achieve the desired scenario.

Thanks

[Gostev]

@wishr not sure I understand your response. All he needs is archive GFS points to object storage, which is Move Mode (available today).

@BigChungus it sounds like everything you need is doable in the current product version. And in fact is the most common usage scenario for the Capacity Tier today. All you need a Backup Copy job with GFS schedule set, pointed to SOBR with Capacity Tier enabled. If you set the Capacity Tier offload period to 7 days, all your GFS fulls will be moved to object storage, just as you want.

Your confusion may come from trying to find GFS retention settings in the Capacity Tier itself. However, they are managed by backup policies instead. Because not everyone will use scale-out repositories and object storage integration, but almost everyone needs GFS.

[BigChungus]

Appreciate the responses @wishr and @Gostev! I think I'm starting to get a little closer to a valid configuration. Any feedback on the following would be immensely helpful.

In my scenario the source backup repository that is targeted by my daily backup job (synthetic fulls every 7 days & 28 restore points) and performance tier storage of my SOBR configuration will reside on the same NAS. Am I correct in assuming this means when the first copy interval is initiated and subsequent incremental are generated each day thereafter by my backup copy job I will then have two copies of the same data on the same NAS?

Also for the backup copy job I plan on setting the "restore points to keep" at 2, with a GFS policy configured for 12 monthlies, 4 quarterlies, and 1 yearly, with "read the entire restore point from source" enabled. The SOBR will be configured to move backup files older than 0 days (not sure why I would set to 7 days as suggested). If I'm sourcing the backup copy from a 10 TB backup job sitting in my source backup repository will the backup copy GFS lifecycle policy play out as such:

1) Initial copy interval copies the 10 TB into the performance tier backup repository associated with my SOBR.
2) Copy interval creates an incremental once a day everyday until it surpasses the limit of 2.
3) Once second incremental is created "restore points to keep" setting gets triggered and injects data blocks from the first incremental backup in the chain into the full backup created by the initial copy interval moving the full backup one step forward in the backup chain.
4) Once the full backup moves forward and lands on the first Sunday of the month it's then assigned a GFS flag and then the next day after the new full backup is generated by the copy interval the monthly full with the GFS flag is then considered inactive and older than 0 days thereby allowing for it to be fully offloaded to capacity tier (object storage).

[Gostev]

You really should not point Backup Copy job to the same storage as your primary repository. This is against 3-2-1 backup rule, as this means all your recent backups will be lost of your NAS dies... so this is really a bad design, if you want our honest feedback.

Otherwise your summary is mostly correct except injection in (3) will never happen if you have "read the entire restore point from source" enabled. Instead, it will be a regular incremental backup chain for Backup Copy job. Which in turn also means your limit of 2 recent restore points will always be exceeded - as by nature of incremental backups, the latest increment in chain requires the entire incremental chain. So in your case, the previous incremental chain can only be removed by the recent backups retention policy after the next GFS full and 2 additional increments are created.

[BigChungus]

Makes sense. Lets say we do assign the source backup repository to a SAN or DAS tied to the Veeam server and allocate the performance tier of the SOBR to NAS does the aforementioned GFS lifecycle still work as described? Specifically steps #3 and #4. I'm trying to understand what would be the logic of setting the data offload value to anything, but 0 in my scenario.

Thanks!

Edit: Just saw your latest reply! Will review.

[Gostev]

The logic behind this value is keeping most recent restore points on-site for fast and free restores. If you offload everything to object storage as soon as possible, then all your restores from backup copies will have to be served from there, which can be both slow (thus impacting your RTOs) and expensive (due to egress and API costs). Just something to keep in mind with low values.