Immutability with GFS - Wasabi

[jphippshbg]

We are starting the process of moving off tapes and over to cloud storage with Wasabi.
We have (3) offices, our main headquarters running Veeam 11a and two remote offices running Veeam 12. Initially we were moving all of our VMware VMs back to headquarters to an HP server/NAS for our performance tier and then backing that up to tapes.
This year we purchased two NAS devices (iSCSI) for our two remote offices, each with a Veeam license, and have been moving those backups local to the remote office. I set each office up with this NAS for the performance tier and then SOBR with Wasabi for the capacity tier. All of that has been working well but my concern is long-term storage since we are not bringing them back to headquarters to put on tape.
Looking at previous posts, I saw where the Capacity tier uses Repository immutability, which is 90 days max in the UI. Since Wasabi doesn't offer an Archive Tier, 90 days does not seem enough for more than 3 monthly.
It seems that GFS is the way to achieve what I'm looking for but I'm concerned about the immutability.
What is the best way to handle monthly and yearly, as we do tape when using Wasabi as our cloud solution?
Thanks

[Mildur]

Hello jphippshbg

If you want immutability for the entire GFS time period, leverage direct backup copy to object storage (Available with v12). Direct backup copy to object storage (no SOBR required) will store GFS backups for their entire time period. You can configure an immutability period of 30 days, but objects belonging to tagged gfs backups will be kept for the entire gfs retention.

Looking at previous posts, I saw where the Capacity tier uses Repository immutability, which is 90 days max in the UI.

If I remember correctly, you can go higher than 90 days with PowerShell. But I don't recommend it. You will make each object undeletable for a long time. It won't be possible to remove objects/data from daily restore points which became outdated.

Best,
Fabian

[jphippshbg]

Thanks so much, Fabian.

With that said, if we are backing up to a performance tier, is there still a need, in version 12, to use SOBR?
It seems like Direct to Object Copy would take the place of offloading the Performance Tier to the Capacity Tier (taking the place of the tapes we currently use at headquarters), at least in this example.

Pardon my ignorance here, but our Performance and Capacity Tier are combined as the SOBR repository and if I create a new job there is not an option to point to the Performance Tier anymore.
Will we need to remove our SOBR repository (freeing up the Performance Tier), point our backup jobs back to our Performance Tier, set up GFS on this backup job, and then do the backup copy on this original backup job to the Capacity Tier?

It would appear to accomplish the following things.
1. Give us a backup copy of the servers/files to an on-prem location (Performance Tier) for 14 to 21 days of backups.
2. Give us a GFS set of 4 weekly, 12 monthly, and 5 yearly to be offloaded to the Capacity Tier which would then hold on to those for the GFS periods giving us not only tape-equivalency but also ransomware protection as recent as the previous week.

[Mildur]

You're welcome.

With that said, if we are backing up to a performance tier, is there still a need, in version 12, to use SOBR?

No, a SOBR wouldn't be required anymore with the direct backup copy approach.

Pardon my ignorance here, but our Performance and Capacity Tier are combined as the SOBR repository and if I create a new job there is not an option to point to the Performance Tier anymore.

Remove the Capacity Tier from the SOBR. Then you can still use your SOBR for the backup job and it won't offload data to the old capacity tier. The backup copy job would copy the backups from the SOBR to the standalone Object storage repository.

backup copy on this original backup job to the Capacity Tier?

We don't call it capacity tier when we are talking about direct backup/backup copy to object storage. It's just an object storage repository.

I suggest the following configuration for your scenario:

Repository
1. Repository for backup jobs: Keep your SOBR, but remove the capacity tier
2. Repository for backup copy jobs: Wasabi object storage (new bucket)

Jobs
1. Keep your existing Backup Job with the SOBR as a target. Retention 14 to 21 days.
2. Create a new backup copy job with the Wasabi object storage as a target (Immutability for 30 days), Retention 30 days, GFS 4w, 12m, 5y
--> Daily backups are immutable for 30 days, GFS backups will be immutable for their entire retention period.

Please note: Till the data on the capacity tier is aged out, you will use two times of the backup space on Wasabi. Direct backup copy and capacity tier copies do not use the same objects on object storage.

Best,
Fabian

[jphippshbg]

Thanks so much, Fabian!
This appears to be doing what we need in our first remote office so I'm about to do the same for our second. After that, I'll be upgrading headquarters.

I know that Windows 10/11 is supported to run VBR. Headquarters is currently running it on a Server 2012 R2 VM but I'm considering putting it on a workstation version too.
I asked another group about this, and someone brought up the concern of using Windows 10/11 in a "server" capacity and Microsoft licensing.
Has anyone seen anything like this before or have similar concerns with licensing?
Has anyone migrated their VBR 11a to a Windows workstation to run VBR 12?

Thanks!

[kristofpoppe]

I was wondering if it was possible to ONLY store the weekly, monthly and yearly full backups in Wasabi. Otherwise with the copy job you keep your daily restore points both local and in Object storage.

[Gostev]

Whenever long-term retention is a requirement, you're almost always better off using AWS or Azure where you can move those monthly/yearly full backups to really cheap archive-class storage with SOBR Archive Tier. Wasabi being hot storage is perfect for relatively short-term retention, but it's too expensive to store data for years (comparing to alternatives).

As for weekly vs. daily, there's almost no difference what to do actually. Either you're moving 5% of changes every day with daily, or 25% of changes once a week. But you need to take the data over to Wasabi and store it there either way.