Issue Error:030000BD:digital envelope routines::update error

[Bitpalast]

In ticket 95402670 I asked support to provide a method to manually tar the locally generated backups so that we can manually upload them to an external storage. The command provided works so far that it creates the .tar file including all the backup content. But it fails at the end with the same error:

[root@servername dumpdirectory]# plesk sbin pmm-ras --export-dump-as-file --dump-file-specification=backup_2411172239_2411192238.tar --dump-specification=/dumpdirectory/backup_info_2411172239_2411192238.xml
Cannot update digest: error:030000BD:digital envelope routines::update error
exit status 1

So the root cause is to be found in pmm-ras, and I assume it's about signing the backup.

What's the status of this case? Is the urgency understood by developers? This is nothing that can wait. Solution desperately needed.

 

[Sebahat.hadzhi]

Thank you for the update, Peter. Our engineers are currently working on resetting signature calculator before archive flush. The ETA for the hotfix release is the 25th of November. Of course, the team will do their best to release it as soon as possible.

 

[macadia]

25th of november? Amazing... Meanwhile, we still cannot make remote backups with the loss of time and resources that this implies and paying the licenses we pay.

 

[jPG]

Same issue on two servers here after updating to AlmaLinux 9.5 (Teal Serval)
Plesk Obsidian 18.0.65 Update #1
The 25th of November seems a bit too far for such a critical issue...

 

[Maarten]

Thank you for the update, Peter. Our engineers are currently working on resetting signature calculator before archive flush. The ETA for the hotfix release is the 25th of November. Of course, the team will do their best to release it as soon as possible.

This raises the question of why the engineers couldn't foresee this issue. I fully understand the workload and challenges faced by the development team.

However, it's not the first time that remote FTP backups have stopped working after an OS update. Considering that the release schedules and beta versions of operating systems are publicly available, were tests conducted with these beta versions to identify potential issues beforehand?

 

[Clicdominio]

We are experiencing the exact same issue on our server. Initially, we assumed it was an internal problem with OpenSSL, so we spent nearly the entire morning investigating, reviewing configurations and logs, and trying different solutions without success.

It wasn’t until we checked this forum that we realized the issue is widespread and not exclusive to our installation. Frankly, it is completely unacceptable that, according to Plesk, the solution to this bug will take five days to be implemented. This is a critical issue affecting the functionality of backups, which are essential for any system.

What are we supposed to do in the meantime? Backups are crucial for the security and stability of our data, and not having an immediate fix puts our operations at risk. Could the Plesk team at least provide a temporary solution or a workaround while the official patch is released?

We urge the Plesk team to prioritize this matter and provide regular updates. Additionally, if anyone has found an effective temporary solution, we would greatly appreciate it if you could share it here to assist those of us dealing with this issue.

We look forward to clear and prompt responses from the Plesk team.

 

[Maarten]

For those using Hetzner's StorageBoxes, it's possible to mount these boxes via SSHFS and schedule backups as if it were a regular mount. You can find a helpful tutorial here: Automount Filesystems with Systemd.

However, there is an important caveat: the Plesk Migrator will not work properly when the backup location is set to the SSHFS mount. If you need to migrate a subscription, you'll face issues.

To work around this:

1. Temporarily revert the backup location to /var/lib/psa/dumps by updating the /etc/psa/psa.conf file.
2. Perform the migration.
3. After completing the migration, set the backup location back to the SSHFS mount.

This workaround ensures both backups and migrations function as needed.

 

[Sebahat.hadzhi]

Hello, everyone. This is just an estimate, we will do our best to release the fix earlier than that. In the meantime, the workaround we can suggest is:

1. Connect to the server via SSH.
2. Navigate to this directory:
   
   

   /usr/local/psa/admin/sbin/

3. Create a backup copy of the pmm-ras file using the following command:
   
   

   cp -a /usr/local/psa/admin/sbin/pmm-ras /root/pmm-ras_backup

4. Remove the original file:
   
   

   rm -f /usr/local/psa/admin/sbin/pmm-ras

5. Upload the pmm-ras-rhel-alma-9.x-plesk-18.0.6x.tgz file attached in this ticket to the /usr/local/psa/admin/sbin directory.
6. Extract it as follows:
   
   

   tar -xvzf pmm-ras-rhel-alma-9.x-plesk-18.0.6x.tgz

You may download the archive from here.

 

[Sebahat.hadzhi]

This raises the question of why the engineers couldn't foresee this issue. I fully understand the workload and challenges faced by the development team.

However, it's not the first time that remote FTP backups have stopped working after an OS update. Considering that the release schedules and beta versions of operating systems are publicly available, were tests conducted with these beta versions to identify potential issues beforehand?

It could be difficult to fully anticipate such changes even with beta testing, especially when multiple software components are involved. To be frank, I am not entirely sure how was this overlooked, but it will be certainly addressed further.

 

[helio.pereira]

Hello, everyone. This is just an estimate, we will do our best to release the fix earlier than that. In the meantime, the workaround we can suggest is:

1. Connect to the server via SSH.
2. Navigate to this directory:
   
   
3. Create a backup copy of the pmm-ras file using the following command:
   
   
4. Remove the original file:
   
   
5. Upload the pmm-ras-rhel-alma-9.x-plesk-18.0.6x.tgz file attached in this ticket to the /usr/local/psa/admin/sbin directory.
6. Extract it as follows:
   

You may download the archive from here.

Thank you so much for helping with this, I already applied the solution to my server and the remote backup on Google Drive worked perfectly. I am anxious for a definitive solution.

 

[Bitpalast]

Hello, everyone. This is just an estimate, we will do our best to release the fix earlier than that. In the meantime, the workaround we can suggest is:

1. Connect to the server via SSH.
2. Navigate to this directory:
   
   
3. Create a backup copy of the pmm-ras file using the following command:
   
   
4. Remove the original file:
   
   
5. Upload the pmm-ras-rhel-alma-9.x-plesk-18.0.6x.tgz file attached in this ticket to the /usr/local/psa/admin/sbin directory.
6. Extract it as follows:

You may download the archive from here.

I've tested this and it is working here. I did a test-backup to a remote FTP storage location and a restore of that backup. Both have worked.
Thank you!
Now let's hope it also works for the full server backup and increments.

 

[macadia]

I've tested this and it is working here. I did a test-backup to a remote FTP storage location and a restore of that backup. Both have worked.
Thank you!
Now let's hope it also works for the full server backup and increments.

+1 tested and it's working fine with remote FTP backup (domain backup). Thanks

 

[Clicdominio]

Hello, everyone. This is just an estimate, we will do our best to release the fix earlier than that. In the meantime, the workaround we can suggest is:

1. Connect to the server via SSH.
2. Navigate to this directory:
   
   
3. Create a backup copy of the pmm-ras file using the following command:
   
   
4. Remove the original file:
   
   
5. Upload the pmm-ras-rhel-alma-9.x-plesk-18.0.6x.tgz file attached in this ticket to the /usr/local/psa/admin/sbin directory.
6. Extract it as follows:

You may download the archive from here.

We have followed the provided steps, and now the backups are working correctly. We appreciate the quick response in offering this workaround while waiting for the official patch.