Copying only full backups to capacity tier

[wa15]

We are looking at keeping 8+ years of data for archival purposes. This would be one backup of select systems twice a month. I don't need incrementals. Since I can't directly set this in backup job or SOBR settings, can I do the following?

Create a backup copy job that copies VM data from local backups once every two weeks. Only keep 2 restore points. Point this to the SOBR. And then set SOBR to offload anything older than 13 days to the cloud. That should copy the latest VBK off to the cloud and leave the incremental on-premise. Then the following run, the parent VBK should be updated, off-loaded to the cloud and so the cycle continues.

Does this practice make sense long-term? Any better way to accomplish what we are trying to do?

[Andreas Neufert]

This will not work that way.
Configure SOBR for the daily backup (it will help to protect the actual environment and to be inline with the 3-2-1 rule). Even if you just select 2 restore points. Then define GFS points for the monthly creation and define Cloud Tier for this repository to be offloaded after 1 day. This will offload the monthly immediately to cloud.

[wa15]

Thanks, it seems like even with the GFS settings, we would still have incrementals created as we can't set the number of simple restore points to zero. However, I am trying to avoid keeping any incrementals in the capacity tier (similar to how on tape you could only write full backups).

Example:

Restore Points to Keep: 2 (minimum allowed)

Weekly backup 0
Monthly backup 1
Quarterly backup: 0
Yearly backup:0

It would keep one full backup on first Sunday of month, followed up 2 days of incrementals. This is the help file I am referencing: https://helpcenter.veeam.com/docs/backu ... l?ver=95u4

Am I not understanding something correctly?

[jmmarton]

The backup copy job is a forever forward incremental. It doesn't matter if it's set for 2 restore points or 20 or 200... none of that will get offloaded to the capacity tier because it will never be sealed. If you're using the BCJ as the source for capacity tier, it's only the GFS points that will ever get offloaded. So in your case define however many RPs you'd like in the BCJ. Then configure monthly as you've suggested.

At that point there's no need to wait 13 days in the capacity tier settings unless you need to keep the GFS point around for a couple of weeks first. You could set that as low as 0 which is move the GFS point to the capacity tier as the very next scan (every 4 hours).

Joe

[wa15]

Thanks Joe. That makes sense. As far as how often to copy data over (defined in the job section of BCJ), I am trying to understand how that ties in here? I suppose that doesn't really matter as it can be set to copy over every 7 days, then setting the monthly GFS to monthly backup of 1. So once a week, we would have an incremental, and then once a month a VBK to be offloaded. Is that correct?

[jmmarton]

If you set the BCJ "copy every" setting to 7 days, that's how often you'll see a restore point created up to the "restore points to keep" setting. So if you set that to two that means the first time it runs it will create a full in the target repo, then 7 days later an incremental, then 7 days later another incremental with the previous one being merged into the full. Keep in mind that means 7 days worth of changes from the primary job will all be copied into a single incremental, making it larger than you might expect. If you want to reduce the space in that repo you could keep it at the default of every 24 hours which means you'll have two days' worth of backups in the target, one full and one incremental.

That part of the BCJ is unrelated to anything with Capacity Tier. It's only the GFS retention in BCJ which is applicable, and those (by default) are synthetic fulls produced by reading the content of the RPs created by the BCJ. Think of Capacity Tier, then, as a separate policy within SOBR to move older standalone/sealed backups to object storage. The primary RPs created by BCJ are never sealed so they never come into play.

Make sense?

Joe

[wa15]

Thanks Joe. Appreciate the response. I THINK I understand. So in order to keep a monthly backup for 8 years, I could configure the BCJ as below:

Copy every 7 days (only have 10TB in full backups and about a weekly 300GB change rate)
Restore points to keep: 2 (first would be a full, second would be incremental, and third one would transform the previous incremental to full. I don't need any more restore points on the SOBR as it's for cloud archive only)

GFS:
Weekly backup: 0
Monthly backup: 96 (one full backup per month for 8 years)
Quarterly backup: 0
Yearly backup:0

Is that correct? Any better way to configure it?

[veremin]

Looks good to me, and don't forget to configure operational restore window in Capacity Tier settings - move backups older than, say, 14 days to object storage. Thanks!

[geets]

[...]
Copy every 7 days [...]
Restore points to keep: 2 [...]

GFS:
Weekly backup: 0
Monthly backup: 96 (one full backup per month for 8 years)
Quarterly backup: 0
Yearly backup:0
[...]

Hi, sorry for digging out that old thread. But I'm trying to understand something here:

Will there ever be a monthly backup with a GFS-flag on it?
Since theres only two restore points and they are 7 days apart from each other there's only ever a 14 days old restore point.
And this (oldest) restore point gets deleted when the next one comes in.

Thanks in advance
Alex

[veremin]

Will there ever be a monthly backup with a GFS-flag on it?

Correct, as soon as the oldest restore point (.vbk) reaches the specified date (GFS monthly restore point creation date), a monthly GFS restore point will be created.

It might be worth checking the corresponding section of our User Guide to clarify how GFS retention scheme works.

Thanks!

[geets]

@veremin Thanks for your reply.
I will check out the user guide again.

For clarification:
In this specific case, where the oldest restore point is at maximum 14+6 days old, no monthly restore point gets created?

[veremin]

Nope, monthly restore point will be created, since you've enabled monthly GFS retention policy.

I do believe that checking corresponding section of our User Guide will help you grasp this and other concepts better.

Kindly, reach us afterwards and we will clarify the missing parts (if any is left).

Thanks!