SOBR - Switching Capacity Tier Vendor


Userlevel 5
Badge +2

Introduction

Veeam Capacity Tier allows the addition of an object storage-based extent to a Veeam Scale-Out Backup Repository (SOBR). This object storage could be on-premises or could be hosted by a cloud provider. Regardless of your chosen platform, Capacity Tier provides a cost-effective way to tier backup data from on-prem 'Performance' extents to Object for longer-term storage.

We encourage you to read and understand the Product documentation on Capacity Tier at https://helpcenter.veeam.com

There are a number of reasons why switching Capacity Tier vendor might make sense to you. Perhaps there was a change in your corporate strategic alliances, or perhaps a simple cost analysis has revealed that deeper savings could be found elsewhere.

Switching object vendor comes with a few challenges:

  • You need to keep your old Capacity tier around until its retention expires and you want to be able to restore from it as well.
  • You don't have "spare" performance tier storage available and thus creating a new SOBR with cloned jobs is not an option.

 

Whatever your reasons are for switching, this document gives you 2 options to meet these challenges, and the processes themselves are very straightforward.

 

Option 1: Simply replace the capacity tier in the existing SOBR

  • Disable backup jobs targeting your SOBR
  • Edit your SOBR and simply select the new capacity tier (vendor 1 to vendor2 in this example)
  • Re-enable your backup jobs

All new offloads will now occur on the vendor2 capacity tier!

 

Note that vendor1 capacity tier's data is untouched but won't be accessible even if you attempt to import.

  • Below, you can see that the import is successful but notice the "skipped" note. This is because the original extent and SOBR still exist.

Our documentation states that the import will only show data when the original SOBR is no longer available (https://helpcenter.veeam.com/docs/backup/vsphere/osr_import_backups.html)

  • You can confirm that vendor1's data is still here by browsing the bucket directly or by declaring that capacity tier repository on a different VBR server.

 

Option 2: Create a new SOBR using the original performance tier's extents and the new capacity tier

  • Disable all jobs pointing to your SOBR
  • Add a "dummy" performance extent to your existing SOBR so you can remove the existing performance extents

!!! This step is crucial to properly free up the extents and unbind them from the existing SOBR !!!

You will get a warning message like the one below.

  • Create the new SOBR using the now-free performance extents and the new capacity tier vendor. Re-scan and you should see imported backups from the performance tier extents.
  • Clone your original jobs and point them to the new SOBR and don't forget to map backups. Lastly, re-enable the cloned job and delete the original jobs.

 

At this point in time your new jobs are ready to go and pick up where you left of. Subsequent offload operation will occur on the new tier (vendor2).

 

To perform Restores from the old capacity tier (vendor1) you can:

  • Access them from the "Object Storage (Orphaned)" folder, if you have kept the old SOBR in place.

-- OR --

  • If you have properly deleted the SOBR (i.e. remove capacity tier 1st to ensure it is unbound from that SOBR) then you can perform an import of the old capacity tier
  • The backups will be made available in the "Object Storage (imported)" folder
  • Don't forget to detach when done with your restore operations

 

In summary, changing your Capacity Tier vendor need not be an impossible task (Veeam loves portability, after all) and this article has highlighted a few considerations and steps to follow depending on your scenario.


6 comments

Userlevel 6
Badge +1

Veeam 12.1.1 here. I did this before and I was quite certain that when I switched from AWS S3 bucket to Wasabi bucket by simply replacing the capacity tier extent in SOBR settings,  I was asked if I want to offload all existing backup or just that last one. This time it did not ask and is now uploading _a_lot_ of backups.

What I did:

  • create new repo with Wasabi bucket
  • replaced capacity tier bucket in SOBR settings
  • started a manual tiering task
  • importing backups from old S3 bucket works, without removing old SOBR (I think this was changed a while ago). Can’t confirm this works as backup is locked by offload now (at least import tried).

It seems that now all backup are offloaded to Wasabi. This is not my goal, I just want new ones offloaded as I have access to the old ones after import. I’m pretty sure it worked that way a while ago when I tested migration to Wasabi. Now it seems to behave differently which is an issue as we have many locations with only a small internet connection and offloading all backups will take weeks.

What am I missing?

 

Edit: if I first disable capacity tier completely, exit the configuration and then add the new bucket I get asked at the end if I just want to copy latest or all backups. If I just unmark the old bucket and mark the new bucket in the selection, it’s working differently. Not really intuitive. 

Hi,

I need to save the backups now in a new azure storage account.

I want to have access to the backups that are in the azure storage account that will be orphaned.

I found this procedure and am trying to use option two.

1 - Is it to remove the performance tier that was being used and keep only the "dummy"?
2 - Is it to maintain the capacity tier (extend scale-out) with the current azure storage account?
3 - When he says to create a new SOBR, does he mean to use the performance tier I removed in option (1)?

I tried to perform this procedure, but the status is like this until now.

 

 

Right after like this:

 

Tks.

Userlevel 5
Badge +2

just for information… sandroalved did a duplicate post on R&D forums with https://forums.veeam.com/post493912.html#p493912

 

Userlevel 7
Badge +8

This is a very well done write up. I feel more and more people need to know this going forward that you are never “locked in” 

Userlevel 7
Badge +20

Very nice write-up.

Userlevel 7
Badge +8

Thanks for sharing, good to know :)

Comment