2x Copies of Backup, One Immutable, with GFS and 3 Different Immutability/Retention Periods

[poolshark1]

I'm going to apologize in advance for the length of my post. I’m looking for advice and specific recommendations about implementing immutability in my backup schema and backup infrastructure. I’ve performed countless searches for best-practices or conceptual articles, videos, forum posts, etc. on my specific need. And while I’ve found plenty that cover the “how-to” aspect of setting up immutability, or those that say “yeah, immutability is a good idea”, or setting up some other component, there are surprisingly few that address particulars when it comes to the configurations needed to achieve different immutability periods for the different GFS retention periods on one backup job. Or using GFS along with backup copies, yet still incorporating immutability.

I am well aware that every organization’s retention policies, backup job requirements, backup infrastructure etc. are different, all of which impact how immutability is implemented. And I’m sure that is a contributing factor in my fruitless search for a clearly defined “best practice” guide. But I need HELP, and I don’t want this to be just another post that gets driven off the road by discussions of backup chain type or object-based versus image-level versus file-level backups or some other setting. I understand that those are all important factors that come into play, and I may actually be searching for a mathematical equation or an online form I can use and apply as variables change in our environment. If that exists, please share a link! Otherwise, I'm honestly looking for “here’s how to set up your environment to accomplish your goals”.

Before I get into my desired outcome, let me provide details on my relevant backup infrastructure.

Veeam Components

• Veeam B&R version 12
• Enterprise Plus licensing with 50 instances

Backup Targets

• VMs hosted in VMware vCenter
• VMware VCSA
• Windows agents on physical endpoints

Backup Job

Despite having different backup target types, for the sake of keeping things as simple as possible, I’m only going to provide relevant details on one target system’s backup job.

• Type = VM object
• Schedule = Daily incremental, every day
• Retention = 30 days
• GFS enabled
  • Keep weekly full = for 4 weeks, use the one from Sunday
  • Keep monthly full = for 12 months, use the weekly full backup from the last week of the month
  • Keep yearly full = for 7 years, use the monthly full backup from December
• Secondary destination = (not currently enabled)
• Synthetic full backup = weekly, on Sunday
• Active full backup = monthly, on the last Sunday of every month

Backup Repositories

• Direct attached storage - Microsoft Windows server
  • The server is a VM hosted in the production VMware environment, with the repository storage presented as a single disk to the VM and backed by an iSCSI-attached SAN dedicated exclusively to Veeam. It is a “Veeam Ready - Repository” Dell PowerVault EMC ME5024 array, so storage snapshot integration, deduplication, and -- most importantly -- immutability are not available.
• Wasabi cloud
  • As many buckets as I need to accomplish my goals

Goals

• 2x copies of every backup
  • 1x in our on-prem Veeam SAN (cannot be immutable due to only qualifying as a “Veeam Ready – Repository”)
  • 1x in our Wasabi cloud extent, immutable
    • 1x weekly full backup every week, to be immutable for 4 weeks (minus 1 day)
    • 1x monthly full backup every month, to be immutable for 12 months (minus 1 day)
    • 1x yearly backup to be immutable for 7 years (minus 1 day)

When I say “minus 1 day” above, I'm taking into account the lessons I’ve seen others have learned about background retention jobs not being able to delete older restore points or chains in a timely fashion due to the immutability period being as long as, or longer than, the desired retention period of a given backup chain/restore point.

To be clear, I already understand the “how-to” portion of a lot of Veeam components – whether it be setting up an immutable repository, a SOBR repository, setting up GFS policies, active fulls, synth fulls, difference between backup chain types, etc. And I know I can extend the immutability period on an object storage repository bucket beyond the default maximum 90 days in Veeam via Veeam PowerShell cmdlets, so I don’t want this to turn into a discussion about immutability periods and what to do there.

I guess what I’m looking for is design advice. I don’t know how to configure the repositories and my backup jobs to achieve my goals efficiently and with no interactive maintenance required. I image the solution may involve backup copy job(s) or configuring the SOBR capacity tier to get a copy of backups as soon as they’re created, maybe multiple Wasabi buckets (each with their own immutability period), as well as at least one SOBR (or more?) with data locality and strict placement enforcement on the SOBR placement policy, and GFS in the backup jobs themselves. But the details are what I’m struggling with. Should I present the Veeam-dedicated SAN to its corresponding Microsoft server as three separate disks (one for daily and weekly backups, one for monthly backups, one for yearly backups), then create three separate Veeam backup repositories (all pointing to the same Microsoft server, but each pointing to a different disk attached to the server)?

Please help! How do I get my goals accomplished with the resources I have?

And if you need to know additional details, I'll be happy to accomodate where possible!

[Mildur]

Hi Daniel

I understand that those are all important factors that come into play, and I may actually be searching for a mathematical equation or an online form I can use and apply as variables change in our environment. If that exists, please share a link!

https://calculator.veeam.com/

1x in our Wasabi cloud extent, immutable
- 1x weekly full backup every week, to be immutable for 4 weeks (minus 1 day)
- 1x monthly full backup every month, to be immutable for 12 months (minus 1 day)
- 1x yearly backup to be immutable for 7 years (minus 1 day)

There are two options on how to use Object Storage. Your requirement with -1 day won't be doable with both of them.

- Direct to Object Storage: GFS backups are immutable for their entire retention time (Example: 1 yearly backup immutable for 1 year, weekly backup immutable for 4 weeks)
- SOBR: 3 backup copy jobs, pointed to different SOBR. Backup Copy Jobs must be configured to run weekly, monthly or yearly. Each SOBR will use a different immutability period. It will work for the weekly and monthly SOBR. The yearly SOBR would have 2555-1 day of immutably. If I remember correctly, the maximum configurable immutability period for object storage repositories is 999 days.

When I say “minus 1 day” above, I'm taking into account the lessons I’ve seen others have learned about background retention jobs not being able to delete older restore points or chains in a timely fashion due to the immutability period being as long as, or longer than, the desired retention period of a given backup chain/restore point.

That shouldn't be an issue with GFS backups. Backups are deleted +1 day after they aged out by the background retention. The GFS restore point is not immutable anymore at that time.

Please help! How do I get my goals accomplished with the resources I have?

To be honest, I recommend to keep it simple with a backup copy direct to object storage. This will set your GFS backups immutable for their entire retention period.
Your goal with the -1 day cannot be achieved (at least not for the 7 year retention) and I also think, it's not required.

Best,
Fabian

[tyler.jurgens]

I will echo Fabian here - go backup copy jobs and set your retention policy as you require. Don't stress about immutability (-1 day) keeping your backups stuck, because Veeam will handle that for you. When the new yearly is marked as a yearly backup, it will remove the objects that went into that 8th-year backup.



Keep in mind though, now all your GFS backups are going to be immutable for the retention period you choose, so you're not going to be able to decrease the retention period to save space and cost, because only the new backups will get marked with a different immutable setting. This is a good thing for security and protecting your backups, but it can be a double-edged sword if you don't like your resulting bill.