What happens when you enable object storage on an existing on-prem repository?

[cerberus]

We've been running VBO 6.x for awhile, backing up EXO/Teams/SP. The local repository has grown to 20TB+ as we've increased our cloud footprint. Looking at enabling object storage, specifically Wasabi.

I tested this using a new job pointing to a new repository that is configured to offload backup data to object storage, seems to work just fine - still a few tests to go.

When I am ready to enable it on my main backup job/repo, wondering what will happen during the next incremental backup run? Will the on-prem repository data be offloaded, or only new incremental data pulled by the job?

How do I get my 20tb repo into the cloud, is the only option using the publicly available PowerShell scripts?

[Mildur]

Hi Mirza

You can't enable object storage on an existing VB365 repository.

You have two options to choose from:
- Reconfigure your job to use the new object storage repository -->
A new Full backup must be created because there is no data in the object storage repository.
Leave the old data on the jet db based repository until it ages out.

- Migrate all data from your jet db based repository to object storage -->
Use this KB article to migrate your data: https://www.veeam.com/kb3067
While the move is running, backup jobs must be disabled. And the move process may take days for 20TB.

Thanks
Fabian

[cerberus]

Hi Mildur,

Thanks for that, I just realized that the option is in fact grayed out. Well that's somewhat of a good thing in the long run, by re-creating the repository its a good time to also get away from the one job (backup entire org) setup we've been running, bring it more into alignment with Veeam best practice to break out Teams, SP, EXO.

For a 20-30TB repository, is there any gain in breaking out Teams, SP, OneDrive, and EXO into multi-job/repo vs. multi-job/single-repo?

Thinking about the 3-2-1 rule, my goal was to keep a local (on disk) and object storage repository, with object storage being our off-site copy (moving away from VBR tapes) and in v7 object locked.

When I re-create the repository with object storage enabled during the creation, VBO is still storing a full copy locally using JET? When one goes to restore, it pulls from local first?

[Mildur]

For a 20-30TB repository, is there any gain in breaking out Teams, SP, OneDrive, and EXO into multi-job/repo vs. multi-job/single-repo?

I recommend multiple repositories depending on your retention requirement. Maybe put SharePoint and Teams to the same repositories because they could share a lot of data (Teams files are on SharePoint sites).
Also keep in mind our recommended configuration maximums. Using a second proxy server means additional jobs and repositories:
https://bp.veeam.com/vb365/guide/design/maxconfig.html

Thinking about the 3-2-1 rule, my goal was to keep a local (on disk) and object storage repository, with S3 being off-site and in v7 object locked.

VB365 doesn't provide offload feature similar to VBR with a SOBR.
You can use local object storage appliance to do the primary backup job. From there you will be able to use backup copy jobs to an offsite object storage with immutability support. Copy Jobs from Jet based repositories to object storage-based repositories will not be possible.

When I re-create the repository with object storage enabled during the creation, VBO is still storing a full copy locally using JET? When one goes to restore, it pulls from local first?

The Jet database is only used for metadata. This metadata is used to optimize costs and performance while doing backup and restores.
For restores, the folder hierarchy is loaded from the cached metadata. And for backups the metadata is used to compare which M365 items are already backed up in the repository.

Thanks
Fabian

[cerberus]

Yeah local object storage appliance would be ideal, I have a commodity Intel server with local storage.

I didn't know that when you enable a local repository with object storage, the "local" part of it just for maintaining metadata in JET engine, I though it stored a copy locally and another in object storage - now I understand this is not the case.

Lets say I am backing up Teams/SP, could I not just create 2 different jobs in VBO; one uses local storage only, and another uses object storage - I would then have "2 copies" of the backup (locally/cloud).