Failed to upgrade capacity tier to a new format

[dello87]

Hello,

I have a similar problem: after upgrade to Veeam V12 some object of my scale-out repository have this error when start the offload process:

Code: Select all

11:03:08 AM	Upgrading backup chain index... 	00:34
11:03:48 AM	Not all storages have been upgraded.  	

in the log:

Code: Select all

[03.04.2023 11:03:57.137] < 35228> arh      | Performing capacity tier upgrade. Failed.
[03.04.2023 11:03:57.137] < 35228> arh      | Destroying CCloudArchUpgradeSessionProxy.
[03.04.2023 11:03:57.215] < 35228> cli      | ERR |Failed to process method 'ArchRepo.UpgradeToV2'
[03.04.2023 11:03:57.215] < 35228> cli      | >>  |Not all storages have been upgraded.
[03.04.2023 11:03:57.215] < 35228> cli      | >>  |--tr:Failed to execute method [5] for class [struct cloudarchlib::archrepo::v2::ICloudArchUpgradeSession].
[03.04.2023 11:03:57.215] < 35228> cli      | >>  |--tr:Failed to invoke method [5] in class [struct cloudarchlib::archrepo::v2::ICloudArchUpgradeSession].
[03.04.2023 11:03:57.215] < 35228> cli      | >>  |--tr:Failed to enum
[03.04.2023 11:03:57.215] < 35228> cli      | >>  |--tr:Failed to upgrade capacity tier to a new format.

Capacity Tier: Azure Blob Storage.
Not all my scale-out repositories are affected by the problem.

Case #05931033

Thanks
Marco D.

[Mildur]

Hi Marco

Your case does not seem to be related to the other case.
I see in the case comments, that you have updated to V12. Then a downgrade to V11 was done. Now you are back on V12 and you see this upgrade issues with the buckets.

Please keep working with your support engineer. We cannot analyze or solve it over the forum.

Best,
Fabian

[dello87]

Hi Fabian,

Yes unfortunately we needed to downgrade to V.11.
We are back on V12 when the Veeam backup appliance for Azure was relised...

Sure I keep working with veeam support.

Best
Marco

[Gostev]

Hi Marco, also for future, it's never a good idea to go back to the previous version after upgrading to a major update simply because the older version won't understand any of the entities updated with the upgrade process (such as new backup metadata versions) and the results are completely unpredictable. Normally the safest in such situation is to start with the new version from scratch, otherwise you may still experience unexpected aftershocks even years from now (including restore failures in the worst possible moment). Thanks!

[dello87]

Hi Gostev,
Yes I Know that downgrade process is not a good things, But in our situation it was the only way to ensure the backup process continuity of one of our production environments...
As you know the backup of production environments is very important and we cannot not have consistent backup every day.

At the moment the Veeam support is working on the problem.

Starting form scratch is absolutely not an option... Starting from scratch it means lost all our backup hystory...

Thanks for your feedback about the topic

Marco

[Gostev]

Why would you lose your backup history? Just keep the old install and let it remove old backups according to their retention policy, then decommission it.

It just really worries me that you want to continue on after being in a completely unsupported scenario. I personally would not do that...

[dello87]

Is not very simple do what you write. Our veeam infrastructure is very articulated and we have yearly retentions to manage.

Anyway I'm just waiting answers from veeam support from about 1 month. Veeam support will tell us what is the better solution to solve our problems.
I think that if the solution is really what you have write, Veeam support will communicate us the better way to do that...

I personally prefer follow what the veeam support tell us...