We have the requirement to save certain backups for 10 years with immutability.
Because of legal reasons.
We use VBR13 with SOBR and local NFS storage as performance tier where we keep the recent 10 days and
also everything is copied/moved to Wasabi as Capacity tier from day1 till 10years with GFS enabled.
Ideally you would want to control the retention and immutability through the backup job settings but for
this the archive tier is mandatory to "offload" the GFS backup to.
First problem is that Wasabi does not support Archive Tier Storage and there are currently no plans to support SOSAPI, so this does not work with Veeam.
Second problem even if Wasabi would support Archive Tier it seems that it is not possible to go from performance tier directly to Archive Tier in SOBR.
It seems to be mandatory to have Capacity Tier in place and then only Archive Tier can be used.
And since both Capacity Tier and Archive Tier would be (external) on Wasabi I guess backups would then be downloaded from Capacity Tier to onprem
and then be uploaded to Archive Tier since we have no Veeam GW servers on Wasabi and I don't think Veeam can tell Wasabi to move the backups "internally"...
So this would be a very inefficient ways to handle the backup "archiving"...
Also that would probably mean we need to keep more than 10days of backups onprem if in GFS 6 weeklies is configured...
Option 2 would be to set the minimum immutabiliy period directly on the Wasabi Object Storage repository in VBR.
But here the only max. 999 days is supported. But we need at least 3650 days!
We have to go for this option since Wasabi has no Archive Tier and also how Archive Tier currently works it would not really work for us.
On VBR it seems there was an option to tweak this up to 27+ years.
We also tried this with our VBR13 but it doen't work.
https://community.veeam.com/blogs-and-p ... weak-10831
We need quick solution on this because we currently cannot fulfill the requirements which we already contractually obliged to!
---
I also a related support case on this.:
Case #08069474 — Questions on maximum immutability period with SOBR and Wasabi as capacity tier
Best Regards
Udo
-
uk1984
- Service Provider
- Posts: 61
- Liked: 5 times
- Joined: Dec 04, 2023 10:00 am
- Full Name: Udo Kloos
- Contact:
-
david.domask
- Product Manager
- Posts: 3645
- Liked: 885 times
- Joined: Jun 28, 2016 12:12 pm
- Contact:
Re: minimum immutability duration with Wasabi is only 999 days - we need 10 years!
Hi Udo,
Few things to note:
- Retention based immutability is planned for Capacity Tier in our upcoming release, but not sure if that will be soon enough for your current predicament
- Direct to Archive Tier does not require capacity tier, but I understand you're already using Wasabi as your capacity tier
May I ask, is the Scale-out repository & Capacity Tier required for your setup? Currently you can achieve what you're looking for by using a Backup Copy job with GFS and targeting a Wasabi bucket directly as opposed to using capacity tier. You can retain your short-term retention on the local NFS storages and configure the backup copy to retain the yearly backups as needed and use the retention-based immutability in this case.
Support is correct that Archive Tier could help here, but if you don't already have an S3 storage that can provide the role of archive tier, then I would consider either waiting for retention based immutability with Capacity Tier or consider switching to Direct Backup to Object Storage with a Backup Copy Job as prescribed.
Few things to note:
- Retention based immutability is planned for Capacity Tier in our upcoming release, but not sure if that will be soon enough for your current predicament
- Direct to Archive Tier does not require capacity tier, but I understand you're already using Wasabi as your capacity tier
May I ask, is the Scale-out repository & Capacity Tier required for your setup? Currently you can achieve what you're looking for by using a Backup Copy job with GFS and targeting a Wasabi bucket directly as opposed to using capacity tier. You can retain your short-term retention on the local NFS storages and configure the backup copy to retain the yearly backups as needed and use the retention-based immutability in this case.
Support is correct that Archive Tier could help here, but if you don't already have an S3 storage that can provide the role of archive tier, then I would consider either waiting for retention based immutability with Capacity Tier or consider switching to Direct Backup to Object Storage with a Backup Copy Job as prescribed.
David Domask | Product Management: Principal Analyst
-
uk1984
- Service Provider
- Posts: 61
- Liked: 5 times
- Joined: Dec 04, 2023 10:00 am
- Full Name: Udo Kloos
- Contact:
Re: minimum immutability duration with Wasabi is only 999 days - we need 10 years!
Hi David,
which upcoming release are you referring to?
I heard from support 13.0.2 will be release in a couple of weeks.
Do you mean that?
If so that would be great.
Do I understand correctly that then the Capacity tier gets the same options
which currently are available in the Archive Tier?
"Archive GFS full backups to object storage" ?
If you can share a screenshot of how it will look like that would be nice.
Anything that involves "Archive" setting/configuration in VBR we cannot use
with Wasabi since it seems to check things/requirements which are not met.
We gradually moved on from CopyJobs to SOBR because it is more comfortable/manageable than CopyJobs.
And just offers more flexibility and options than CopyJobs.
Best Regards
Udo
which upcoming release are you referring to?
I heard from support 13.0.2 will be release in a couple of weeks.
Do you mean that?
If so that would be great.
Do I understand correctly that then the Capacity tier gets the same options
which currently are available in the Archive Tier?
"Archive GFS full backups to object storage" ?
If you can share a screenshot of how it will look like that would be nice.
Anything that involves "Archive" setting/configuration in VBR we cannot use
with Wasabi since it seems to check things/requirements which are not met.
We gradually moved on from CopyJobs to SOBR because it is more comfortable/manageable than CopyJobs.
And just offers more flexibility and options than CopyJobs.
Best Regards
Udo
Who is online
Users browsing this forum: Semrush [Bot] and 4 guests