v12 download from object storage fails due to encryption

[mcz]

Hi guys,

I know that technical questions about issues are almost every time forwarded to the support, but I'd like to know if such issues are known right now:

Installed v12 on a fresh database. Created an object storage repository (to an existing bucket). Imported Backups (specifying key there), passed key for the decryption of the backups itself, done. So finally I have backups under "Capacity Tier (Imported)". Tried to export a backup, was able to choose one of many restore points, specified target and started the export job. It failed after a minute.

The Vm.<name>.VbkExport.log tells me

Data in the object storage is ecnrypted with a different password.

?? What's wrong here, how can it be a different password when the import was successful? Any ideas, are such circumstances known? All in all, it's not the first time that I'm having issues with imports on a different database and I've got the feeling that some lines of code need to be improved there.

Thanks!

[Mildur]

Hi Michael

I checked our internal bug system and searched in support cases in the last 2 weeks. No cases available with this error message so far.
Can you please open a case with our customer support and let them have a look at your backup servers debug log files?
Please share the case number with us.

I have one additional question. The imported backups are they from a V11 installation or from V12?

Thank you very much,
Fabian

[mcz]

Hi Fabian,

will do, thanks for the response. The backups are indeed from a v11 installation. Is there a incompatibility?

Thanks!

[Mildur]

Maybe there is an compatibility issue in importing V11 capacity tiers in V12.
There was a typo in your provided error message: ecnrypted. So I search also for the wrong one
I checked again and found another case where someone imported a V11 bucket to a V12 backup server. He got the same error as you.
But the question was for another issue not related to yours.

Is the old server still online? Have you put the capacity tier extend in maintenance mode before connecting to the V12 server?

For me, it looks like the V11 server and V12 server are using different ways to store metadata about the encryption key or meta data got corrupted.
A support case will help to confirm it by the logs. If this is a limitation, we need to add it to the user guide.

Best,
Fabian

[Regnor]

So far I haven't seen such problems although I've played a bit with object storage in the last time. I also imported existing buckets to new installations and they did decrypt without any issues.

Just wondering if the update if the index or storage format failed? Have you tried to rescan the object storage?

[mcz]

there is no rescan, because I'm directly importing the backups from the object storage (right click -> import backups)...

[mcz]

case #05909696

[Mildur]

Hi Michael

I replaced your contract number with the case number.
You opened the case for community edition, I try to ask our support management that a engineer takes over the case.

Best,
Fabian

[mcz]

Thanks Fabian. Yes, I was using a fresh installation on my notebook, but as it's not protecting the same environment, I guess I'm allowed to use the same license here?

[Mildur]

Hi Michael

You can use the same VUL/Socket license to protect different environments, as long this environments belong to your company.
Just make sure that this license has enough workloads and an enterprise manager is implemented to manage the total license usage.

Support Management gave the approval to move your case. So you should have an answer soon.

Best,
Fabian

[mcz]

short update: First information from support was that this bucket was part of a SOBR and that's why import won't work in standalone mode - which would be totally different compared to v11 and some statements that have been set by PM team... I'll continue to work with the engineer on that case.

[patrikcze]

Same problem here.

<01> Error Data in the object storage is encrypted with a different password. (System.Exception)

BLOB was part of SOBR before. Now it is imported only. Scan was done. Encryption password entered when BLOB was imported.
Now when trying to run the restore. Getting this message. What is worse, is that this BLOB has been also attached to another VBR server where it is not even possible to read restore points and whole process will fail on database timeout. Which is generating other errors as well. Also update from 11 to 12.

[veremin]

Do you have a support ticket number so we can follow the investigation internally? Thanks!

[mcz]

Patrik,

in contrast to v11, you must not use the object storage on another instance while you're doing the import/restore. As soon as data on the object storage is changed (by doing further offloads, etc.), you will receive errors. My guess is that it has something to do with the metadata, remember the local cache got removed in v12 and it looks like that further writes on the object storage changes metadata which then breaks the reading operations on the "other" instance as this instance isn't aware of the changed metadata...

Just disconnect the writing instance (or put objectstorage into maintenance mode), delete the whole database on the reading instance and start over is my advice for now.

[dali@iae.nl]

Case #06378165

On still the same VBR, with v11 we imported 2 older Azure Object Storages. v11 has been upgraded to v12 many months ago.
Now I need to retrieve something, so first time in v12 to retrieve something from old blob storage and got this error.

Please advice how to handle.

[veremin]

The investigation still continues, so keep working with the support engineer who has just requested a full debug log bundle (some log files seem to have been missing in the original email). Thanks!