Resolved 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 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.

 

[AmaZili Communication]

Hello,
Any idea about a date for a fix ?
We feel naked without external backups of our servers !

 

[cmaxwell]

Hello,
Any idea about a date for a fix ?
We feel naked without external backups of our servers !

Check the previous messages in this thread - a temporary fix has been issued.

 

[macadia]

The temporary solution is here Issue - Error:030000BD:digital envelope routines::update error

 

[AmaZili Communication]

Installed the fix, it did not work.

Error Log​

Error:
Unable to create the remote backup: Cannot update digest: error:030000BD:digital envelope routines::update error

 

[AmaZili Communication]

Installed the fix, it did not work.

Error Log​

Error:
Unable to create the remote backup: Cannot update digest: error:030000BD:digital envelope routines::update error

Restart backup and magic happened

 

[occinodo]

If anyone would like to run a script on their RMM tooling, here you go, this worked for us.

#!/bin/bash

# Set variables
TARGET_DIR="/usr/local/psa/admin/sbin"
BACKUP_FILE="/root/pmm-ras_backup"
TGZ_URL="https://support.cpanel.net/attachments/token/mRHWnvEh1prhjg0YITSvI3PnN/?name=pmm-ras-rhel-alma-9.x-plesk-18.0.6x.tgz"
TGZ_FILE="pmm-ras-rhel-alma-9.x-plesk-18.0.6x.tgz"

# Navigate to the target directory
cd "$TARGET_DIR" || { echo "Failed to navigate to $TARGET_DIR. Exiting."; exit 1; }

# Create a backup of the pmm-ras file
if [ -f "$TARGET_DIR/pmm-ras" ]; then
  cp -a "$TARGET_DIR/pmm-ras" "$BACKUP_FILE"
  echo "Backup of pmm-ras created at $BACKUP_FILE."
else
  echo "No pmm-ras file found to back up."
fi

# Remove the original pmm-ras file
if [ -f "$TARGET_DIR/pmm-ras" ]; then
  rm -f "$TARGET_DIR/pmm-ras"
  echo "Original pmm-ras file removed."
else
  echo "Original pmm-ras file does not exist. Skipping removal."
fi

# Download the new pmm-ras file
wget -O "$TGZ_FILE" "$TGZ_URL"
if [ $? -eq 0 ]; then
  echo "Downloaded $TGZ_FILE successfully."
else
  echo "Failed to download $TGZ_FILE. Exiting."
  exit 1
fi

# Extract the downloaded file
tar -xvzf "$TGZ_FILE" || { echo "Extraction of $TGZ_FILE failed. Exiting."; exit 1; }
echo "Extraction completed successfully."

# Set permissions for the extracted file
if [ -f "$TARGET_DIR/pmm-ras" ]; then
  chmod 755 "$TARGET_DIR/pmm-ras"
  chown root:root "$TARGET_DIR/pmm-ras"
  echo "Permissions set for pmm-ras."
else
  echo "pmm-ras file not found after extraction. Exiting."
  exit 1
fi

# Clean up the downloaded tar.gz file
rm -f "$TGZ_FILE"
echo "Cleanup: Removed $TGZ_FILE."

echo "All tasks completed successfully."

 

[Jose Isla]

Hello,

For those of us who have Plesk 18.0.59 installed, logically the provisional solution provided does NOT work.
When entering the Backup Management menu, a 500 error appears.
Do we necessarily have to update Plesk to ; 18.0.6x ?

Any ideas to be able to perform remote backups with Plesk: 18.0.59?

Thank you all.