Simple repo for SOBR capacity/archive tier?

[Vejete]

Must a SOBR capacity or archive tier be object storage? IHAC who wants to make a SOBR from two simple repos. Repo 1 is Linux immutable. Repo 2 is Windows (normal). Cu wants to have restore points go to Repo 1 and live for 45 days there. At the end of 45 days, he wants those restore points to move to Repo 2 where they will live for another 45 days. At the end of 90 days, he wants the restore points to disappear. That gives him 90 days of storage with the first 45 days being immutable.

Everything I can find indicates that the capacity or archive tier must be object storage. I was hoping to find a way to make a simple Windows repo act as the capacity or archive tier of a SOBR while the Linux immutable repo acts as the performance tier. Any ideas?

[Mildur]

They must be a supported object storage.
Archive Tier is only supported with Public Cloud Object Storage. And only if your Capacity Tier is on the same Public Cloud too.

Capacity Tier:
S3-compatible object storage repository
Amazon S3
Microsoft Azure Blob Storage
Microsoft Azure Data Box
IBM Cloud Object Storage
Google Cloud Object Storage

https://helpcenter.veeam.com/docs/backu ... ml?ver=110

Archive Tier:
Amazon S3 Glacier
Microsoft Azure Archive Storage

https://helpcenter.veeam.com/docs/backu ... ml?ver=110

[Vejete]

Thanks, Mildur.

So it would seem my only option is to find a way for Server 2019 to present direct-attached storage as an S3 compatible object store in order to use it for the capacity or archive tier of a SOBR. Rats.

Maybe I'm the only one on the planet who wants SOBR functionality that will target one extent for all new backups and move backup chains of a prescribed age to a second (non-object) extent for the remainder of its overall retention.

Backup copy is off the table, because it grabs the most recent source versus the oldest.

A concept that seems so simple has suddenly become quite complex.

[Mildur]

No problem, happy to help.

So it would seem my only option is to find a way for Server 2019 to present direct-attached storage as an S3 compatible object store in order to use it for the capacity or archive tier of a SOBR

Only Capacity Tier will work this way.
Archive Tier is dedicated to Azure and AWS Cloud Service. The Veeam software logic will not allow you to use onPremise s3 storage as an archive tier.

I don‘t know a software solution for Windows Server to act as an S3 Storage. There I cannot help you

[Vejete]

Capacity tier would be fine. Here's the deal: Cu has two big Dell servers, each with 144 TB of storage. One system needs to be a tape server, so Windows is required. The other system is Linux so we can have immutability. The pivotal question is thus: If the primary 144 TB repo is on Linux to enable immutability, how can we use the other 144 TB sitting on Windows? Veeam's limitations notwithstanding, my idea was to let restore chains live on the Linux side for half the retention period then roll over to the Windows side for the other half of their natural lives thus leveraging the entirety of the combined 288 TB of DAS that's split between Linux and Windows systems.

Sadly, until a simple repo can be a SOBR capacity tier or until Veeam supports Linux for a tape server, it looks like I'm borked.

[Mildur]

Understandable.
Veeam is looking into Tape Server on Linux:
post412051.html#p412051

Are you using Fast Clone on the windows server? With backup copy Job and Fastclone, the synthetic fulls will be mostly spaceless. Would that be an option? With tapes, you have your air gapped backups, and your most recent backups are immutable too on the Linux hardened repo.

This could be a scenario:
1) Backup Job to Linux hardened Repo (xfs filesystem for FastClone)
2) Backup Copy Job to Windows Repo (reFS filesystem for FastClone)
3) Tape Job from Windows Repo to Tape



You could make a calculation to see if the space would be enough with the FastClone feature.

https://rps.dewin.me/

[Vejete]

Muldur, you and I were thinking along similar lines. That would be a decent Plan B.

We had a good discussion over lunch, the customer and I, and here's what we decided to do: Find a recently retired 1U or 3U server with decent CPU and RAM resources, stuff a pair of FC HBAs in it, and use *that* as the Winblows tape server. That lets us take the 2nd server loaded with storage, make it a second hardened Linux repo. Then we put *both* hardened Linux repos in a SOBR, and we're good to go. Doesn't matter where restore chains reside - they will have their desired immutability. And we benefit from the aggregate storage space. Win-Win.

We did in fact go with xfs (reflinks=1 and crc=1) in Linux to support the fast clone synth full option. So we have that going for us, too. Which is nice.

Thanks for your responses. I enjoyed the exchange.

[Mildur]

Of course. Was a pleasure to share my experience, Jim Good plan. That will work for your goal.
I have a similar case, where I will reuse some old retired dell server as a temporary backup repo.