Your operational restore window and retention policy

[psmith023]

Latest Veeam install and have created a few new jobs which will backup locally and then will copy the backups to the Wasabi S3 cloud. I have created the jobs, Local Storage and the Scale Out Wasabi storage. My goal is to backup the 3 VM Hosts to local storage with a 21 day Retention Policy and also to copy the jobs to Wasabi with the same 21 days policy. When the retention policy expires after 21 days, I want the local restore points to be deleted and also have the Wasabi copies deleted. The jobs are completing successfully along with uploading to Wasabi. I am a little confused on the SOBR properties for the Capacity Tier. I have it set to Copy backups to object storage as soon as they are created which it is. I also have Move backups files older than # days (your operational restore window). Should the number of days also be 21 in order to have it delete restore points from Wasabi after 21 days? Everything I am reading says "the operational restore window is the define period after which inactive backup chains on your performance extents would be considered outdated, therefore, should be moved to the capacity extent?" To me, this sounds like once the retention policy expires on the backup job, it will then move those expired backups to Wasabi after a number of days specified. Any help is appreciated. thanks.

[PetrM]

Hello,

The retention policy and the operational restore window are 2 completely different settings.

The first one is the setting of backup job which defines how long backups are kept before they are deleted. This retention policy will apply regardless of backup repository settings, because it defines your business requirements (and is usually driven by policies and regulations that must be strictly followed).

The second one is the SOBR data management setting: once an operational restore window is exceeded, the olders restore points are moved from the Performance Tier to the Capacity Tier to free up the former. This is completely perpendicular and unrelated to the backup job retention policy. In the end, SOBR is no different from a simple backup repository, if you forget about all the smart things it does with the data stored inside of it.

The workflow of "Copy + Move" policy is described in sufficient detail on this page.

Thanks!

[Gostev]

My goal is to backup the 3 VM Hosts to local storage with a 21 day Retention Policy and also to copy the jobs to Wasabi with the same 21 days policy. When the retention policy expires after 21 days, I want the local restore points to be deleted and also have the Wasabi copies deleted.

In that case, you should not enable the Move policy at all - only the Copy policy should be enabled on SOBR CT. And your retention policy on the backup job is set correctly already.

Retention policy: 21 days
Copy policy enabled on SOBR CT.
Move policy disabled on SOBR CT.

However, keep in mind that Wasabi has the minimum storage policy of 90 days. Meaning, you will pay Wasabi for full 90 days of storage even if Veeam deletes backups from Wasabi after 21 days. With this in mind, you may want to consider using the following setup instead:

Retention policy: 90 days
Copy policy enabled on SOBR CT.
Move policy enabled on SOBR CT with 21 days window.

With this approach, you will have 90 days retention policy at no extra costs comparing to the original setup.

[psmith023]

Thanks Peter and Gostev for the explanation. I decided to go with the below:

Retention policy: 28 days
Copy - enabled on SOBR
Move - disabled

I dont have enough local storage for 90 days but 28 should be plenty. I understand the full 90 days and it is what it is. thanks. again.

[Gostev]

@psmith023 perhaps you misunderstood my point. But the following setup only requires enough local storage for 28 days of backups, as everything that is older is removed from local storage once it has been moved to object storage:

Retention policy: 90 days
Copy policy enabled on SOBR CT.
Move policy enabled on SOBR CT with 21 days window.

So, you don't need 90 days worth of local storage with such settings. In fact, this is arguably the most typical SOBR setup out there: small local storage for most recent backups only, with the bulk of backup files stored in object storage.