VBO On-prem repo to Object question

[dhayes16]

Hello All.
So I used the script in the following article: https://www.veeam.com/kb3067 and it seemed to work great. If I try to perform a restore it seems to be pulling from object as expected (I get the warning on restore that it is pulling from object and there might be charges, etc so I know the restore is coming from there.).

However, when I look at the backup job it seems to still be backing up to the local on-prem repo. Also, the storage space for the on-prem repo is still the same size as it was before migration. I assumed that would go down but perhaps not due to the fact that "white space" is added to the original source as per the instructions.

Anyway, does this sound right? I tried to edit the backup job to point it to the object repo but the object repo is not an option oddly enough even though it is configured and it seems accessible.

Thanks for any info
Dave

[Mildur]

Hi Dave

I assume with "VBO On-prem repo" you are talking about jet db based repositories? Object Storage appliances such as Cloudian can also be a "VBO On-prem repo".

Also, the storage space for the on-prem repo is still the same size as it was before migration. I assumed that would go down but perhaps not due to the fact that "white space" is added to the original source as per the instructions.

Correct. Jet databases are not getting smaller when you delete data in it. The database files keep their file size.
New backup data will be stored in the "white space" of the database files.

However, when I look at the backup job it seems to still be backing up to the local on-prem repo.
Anyway, does this sound right? I tried to edit the backup job to point it to the object repo but the object repo is not an option oddly enough even though it is configured and it seems accessible.

You have to manually edit the backup job for the new repository. The situation that you cannot see the new object storage repository sounds wrong.
Please open a support case and provide me with the case number. Our customer support team can check the logs and your configuration to figure out what's wrong.

Best,
Fabian

[dhayes16]

Thank you Fabian for your response. My Case is: Case #06270064

Yes..Sorry...The source repo is a Jet DB based repo stored on-Prem.

Very much appreciated.

[dhayes16]

Hello...Quick update...Veeam support was amazing on this and replied to me within 30 minutes. It appears the problem is that the bucket we created in Wasabi had Object locking and versioning enabled (our fault). It appears this is not supported by VBO as a backup destination likely due to retention settings conflicting with Immutable settings in some way. So in effect, this repo was cut off from being able to back up to it anymore. Fortunately, I can still get to the repo via the VBO interface. However, we need to create a NEW VBO repo for new jobs going forward. Although this is not ideal it will work for us since the repo is rather small and we will just need to know it is there for recovery purposes.

I would suggest that this caveat be added to https://www.veeam.com/kb3067 just in case others make the same mistake we did. I know the limitation is documented in other support articles (Object lock and versioning not being supported for VBO Backups) but it might be worth mentioning in kb3067 as well.

Again, Veeam support was great...Thanks Franco and Fabian!

[Mildur]

Hi Dave

Thank you for the update.
To be honest, it shouldn't be possible in the first place to use the Move-VBOEntityData against repositories with immutably.
Move-VBOEntityData can only move backups from a backup job. And backup jobs can only use repositories without immutability as a target.

Let me check with the team if this is something the command can check when it is executed. We surely will update the kb and fix the command if required.

Best,
Fabian

[Mildur]

Hi Daniel

Our QA team confirmed it as a bug. We plan to fix the behavior in an upcoming version.
I will also talk to our KB team to add it also as a limitation.

Thank you for making us aware of the bug.

Best,
Fabian