The comments are terrible, blaming Oracle (I guess that's trendy these days), some people even advise suing Oracle.
This is a system administration failure, not an Oracle failure. Basically they didn't test their recovery strategy.
This is a system administration failure, not an Oracle failure. Basically they didn't test their recovery strategy.
That's the Oracle failure. "Enabling Oracle encryption according to their instructions, failed to do what it should, and we lost access to all our servers and all our backups because of it".
There's also a separate failure of administration on the client side of not practising working with encryption before using it in production, and not testing recovery and noticing the wallet was empty and the backups were unusable before it became a disaster, but the fact that it did become a disaster is a failure of Oracle's system.
From one of the OP's comments, "Oracle support told him, step by step, to encrypt the database, which happened ages ago and is the root of all of this."
That wallet is the responsibility of whomever created it. Just because it's empty now, doesn't mean it's always been empty. In addition to that, what if the person who initially encrypted everything with TDE, used a local only wallet? This would explain why the ewallet.p12 file is empty. Oracle recommends that you store your master key in the ewallet.p12 file and not the cwallet.sso file, which is the auto-open file, but only on the workstation it was created on.
There could have been multiple failures here with multiple parties and not just Oracle.
It's not an on-prem setup where the customer has full control to manage/test backups, it's at least some level of managed service from Oracle.
So at the least the commands used should have offered/enforced creation of a key backup as part of the encryption process (in the way that bitlocker does for Windows disk encryption) to reduce the risk of something like this happening.
This is way more than enough to turn this over to lawyers and let the court decide who is to blame.
Yes, the company could have checked their recovery strategy but if Oracle claims the key gets written to disk and it wasn't, there is a good chance for at least some compensation from Oracle.
But being a cloud service, it would be odd if the encryption key would be available without any interaction by the owners.
If this was something they ran locally, yet it'd probably be their fault. But this is a hosted solution with a major bug. I hope some Oracle people are searching through seeing how many other customers have this empty wallet bug, and fixing it now.
They could generate a new key + wallet, which could probably then be made to work for the running instance.
All the backups though, would probably need to be opened with the current (missing) key+wallet in order to re-encrypt them.
Might be doable with the current key+wallet that's in memory, but also it might not be. eg might not be able to change the software on the running system, in which case ouch... places that need historical backups (eg for legal purposes) would be in bad place.