pleskbackup - Unable to decrypt backup. Specified key is not suitable.

[danami]

No matter what I do the pleskbackup always give me Unable to decrypt backup error.

Plesk Version
Product version: 12.5.30 Update #15
Update date: 2015/12/16 11:30
Build date: 2015/11/27 16:00
OS version: CentOS 7.2.1511
Revision: 344620
Architecture: 64-bit
Wrapper version: 1.2

First try not using a password
Backup command:
/usr/local/psa/bin/pleskbackup server -s -v

Restore command:
/usr/local/psa/bin/pleskrestore --restore /var/lib/psa/dumps/backup_info_XXXXXXXX.xml -level server

Result:
Unable to decrypt backup. Specified key is not suitable.

Second try using backup password
Backup command:
/usr/local/psa/bin/pleskbackup server -s -v -backup-password tester123

Restore command:
/usr/local/psa/bin/pleskrestore --restore /var/lib/psa/dumps/backup_info_XXXXXXXX.xml -level server -license -verbose -backup-password tester123

Result:
Unable to decrypt backup. Specified key is not suitable.

Any ideas ?

 

[Kate]

Hello,
Please try to apply solution from the KB article below:
https://kb.odin.com/en/120769

 

[danami]

Hello,
Please try to apply solution from the KB article below:
https://kb.odin.com/en/120769

Unfortunately the KB suggestion doesn't work. Setting a backup password was the was the first thing I tried when it failed the first time. As I stated above the restore doesn't work when setting or not setting a password. If you look at both examples I tried both should be valid. Because enhanced security mode was enabled on the server I created the server backup with a password. Even with the password being set and the same password being used with pleskrestore I still got the same error.

 

[Lev]

Hello,

Did you try to restore backup on the same server where backup was created?

 

[danami]

Hello, Did you try to restore backup on the same server where backup was created?

No the backup was being restored on another server. Normally we use pleskbackup to do major OS updates. In this case we were upgrading from Plesk 12.5 on Centos 5 to Centos 7. I setup a fresh server running Plesk 12.5 and Centos 7.2 with the same IP addresses and restore the backup to it. Is there is no way to restore a backup with passwords intact when enhanced security mode is enabled and a backup password was used? If that is the case what happens in the event of hardware failure? In this case the server had less than 20 domains to I was able to do the restore through the Plesk interface but it reset all the passwords. I then used the /usr/local/psa/admin/sbin/mail_auth_view on the old server to lookup all the passwords and set all the passwords back manually. I wouldn't want to do that on a server with a lot of domains.

 

[Kate]

Hello,
Try to use this option in the test set:

/usr/local/psa/bin/pleskrestore --restore /root/backup -level server -ignore-sign -ignore-backup-password

If the backup will be restored, it means that the password you are trying to perform is invalid.

Please note that all the passwords will be dropped after restoration with "-ignore-backup-password" option

 

[danami]

Please note that all the passwords will be dropped after restoration with "-ignore-backup-password" option

Is there no way to backup and restore to another server with all passwords intact? You can see in my examples provided that the same password was used for both the backup and restore.

 

[ipilipenko]

Hello danami,

Seems that the issue is related with password Length. According to our requirements, only keys of sizes 16, 24 or 32 are supported.
Otherwise you will receive the following error in /var/log/plesk/panel.log:

ERR [1] Exception: PHP Warning: mcrypt_cbc(): Key of size 5 not supported by this algorithm. Only keys of sizes 16, 24 or 32 supported;

Please, try to set password of 16, 24 or 32 symbols.

 

[danami]

Thanks for the heads up. I'm thinking that this bug was introduced with PHP 5.6+ as its now enforcing proper key sizes:
https://www.devside.net/wamp-server...gorithm-only-keys-of-sizes-16-24-32-supported

If this is the case this might be a pretty big bug as everyone's backups won't be able to restore with passwords in tact.