I do not see any reported issues regarding encryption keys in this system. I don't know if support ever got a response from that customer. Can you provide any sense of the details around your encryption password. Without revealing what it is, can you give me some parameters to test here? Length and whether you used any advanced Unicode characters and what keyboard language you're running on Windows?

Hey @David Gugick
Thanks for replying. My encryption password is quite long (15+ characters) and complex (combination of letters, numbers and special characters).
However, I've gone further to check on the logging and found few interesting stuff.
Just for context purpose, I have two Cloudberry apps running on different servers

• One is running just fine with the same password. - Version 6.3.3. Its backup items can be restored in both servers
• The other one is what I'm having issue with now. - Version 6.3.1. Its backup items cannot be restored in both servers

I tried to restore on both servers, both failed. Here is the interesting part.
One of the server's logging (Version 6.3.3) show this error

Searching further, this padding issue seems to be related to the Encryption area. But I'm not too familiar with this part.

Can you upgrade 6.3.1 to the same version you are using on the other server and test again. In the meantime, I'm checking with support on that older version.

Support wants you to create a separate backup plan for a single test file, specify very simple 3 digit password and run a test restore to see if that works.

Hi @David Gugick
Unfortunately, I've gone too fast. I've gone to update the 6.3.1 to the latest version 7.1.2 (Update directly from the Cloudberry Backup) After upgrading to this version and run the backup again, restore still failed with the same error.

I've create a separate backup plan on a folder with only 3 simple digit password.
Restore worked with this test backup plan!
Does it mean that this have something to do with my password?

Also maybe worth mentioning that the failed restore process actually runs until several minutes before failed.
I tried another restore process with NO password entered, and it failed directly. So, it seems that it is restoring until certain files (maybe?) then failed.
My another instinct says that could it be that some file (part of the file chain) maybe encrypted with another password?

The logs would probably have additional information as might the backup history for that particular plan. You can go ahead and open the Support case if you want. If the problem is happening with no password then it might not be password related.

Thanks, @David Gugick
I've tried to open a Support case, but unfortunately the Support need an active Maintenance subscription for them to be able to help.

For the test with NO password, maybe I'll re-arrange my wording.
What I mean is that I've tried to do the same Restore again, but without entering any password during the Restore process. And it failed directly saying same issue
So, this is normal I believe.

I'm eager to try this scenario now
Changing the existing backup plan's password to a shorter one and less complex.

However, if I change the password on the existing backup, will it also re-encrypt all my previous backups with this new password? Or all my previous backups will no longer be available?
Just not sure what is this warning means

Just another update here

I've tried to use the same complex password (15+ characters, combination of alphabets, number and special characters) on the Test Backup jobs that I created earlier with 3 simple digit password.

Restore is still successful.

So, not the password.
It could be the Backup job or the File chain now I'm guessing

I've just Force Run Full Backup on the backup jobs. Will post the update here

when you change the encryption password, we require that all the data be backed up in full again. Old backups remain in storage with the older encryption passwords unless removed by retention settings. We did this to make it easier to restore by avoiding having two or more encryption passwords in use simultaneously in the most recent backup of each file.

Full Backup is finish.
Test Restore has a mixed result

• File A - Successfully restored
• File B - Error with the invalid encryption issue again

Both files are backed up using the same backup job plans. Getting more confusing now.
I'll try to narrow down the issue again and will post another update

Please open a support case. If the support team asks, tell them that I was the one that instructed you to open the case. You can easily send the logs to support to kick off this process by using the tools diagnostic option and the toolbar.

Hey @David Gugick
Thanks! That's very kind of you.
I'm doing one more test now which I have a strong feeling might be the cause (I just notice the difference between File A and File B)
If this one fail, then will proceed with the Support ticket

File A and File B now successfully restored.
Will still try with another file later on, but for now I'm pretty sure this is happening

Apologies first! It must have been a combination of several mistakes. The scenario must be like this

• Initial decryption key is actually wrong. That's why when I changed it in the backup plans, it ask

[*] I click OK, thinking it will re-backup all previous backup files (At this point, I didn't run any Full Backup)
[*] First restore attempt still failed - This must be due to no Full Backup run
[*] Create a temporary backup job with a simple password - Second Restore works fine

• This is where my mistake add up. I didn't delete this backup job, causing the file encrypted with different simple password still (Although the file is still in the coverage of the First Backup Plan)

[*] I run a Full Backup job after this and Third restore failed for the File that is backed up by the Test backup plan. I didn't realize this because both File reside in the same folder which is being backed up by Original Backup Plan

I deleted the test backup job, edit the original backup job again with the encryption key (No confirmation happened), re-run full backup and now restore success for File A and File B.

Will try with another few more files just to make sure. But as of now, I believe this is what happening!
Special thanks to @David Gugick for guiding me along.

I've just Force Run Full Backup on the backup jobs.