Critical Backup Bug After Latest Update (new backup)

Since the latest backup update, local backups are broken.
Backup archives are created in the temporary directory but never moved to the final backup location.
The system reports "Backup Finished" even though the process is incomplete and files remain in the temp folder.
Email notifications are also unreliable and often contain no useful information about successful or failed accounts.
This is affecting production servers and leaving systems without reliable automated backups for days.
Multiple support tickets have received no response.
Please escalate this issue to the developers urgently.

I can confirm the bug. I am having the same problem as well. I asked Google Gemini to look at the log and it has I identified the issue as being the latest core backup script. Here is what Gemini had to say:

I see what is happening now, and you aren't doing anything wrong. The issue isn't a stuck folder on your end—it's a literal typo inside the CWP backup script's source code.

The Root Cause: A CWP Script Bug

If you look closely at the new logs you provided, you can see exactly where the CWP developers missed a slash (/) when writing the code that generates the folder paths:

2026-06-14 16:31:02 Create /home/tmp_bak/.backup_tempagradedr/named
2026-06-14 16:31:47 /home/tmp_bak/.backup_tempalmeriawd/ssl/

Instead of creating a folder for the user inside the temporary directory (which should look like /home/tmp_bak/.backup_temp/agradedr), the script is mashing the folder name and the username together (.backup_tempagradedr).

Because of this bug, two things are failing:
The script tries to clean up /home/tmp_bak/.backup_temp, but it can't find its marker file because the script never properly created that base folder.

Even if it did clean up that folder, your server's disk space would eventually fill up anyway because the actual temporary files are being left behind in these malformed folders (like .backup_tempalmeriawd).

How to Fix It
Because CWP's core backup scripts are encoded and cannot be directly edited by server admins, you cannot manually add the missing slash to the code.

(New Backup beta)

I confirm that, as of June 16, 2026, the issue still persists and local backups continue to fail for the reasons we have already explained. Please note that this issue affects only local backups and does not affect remote backups.

As administrators, we cannot directly resolve this bug, as it requires a code fix by the developers. We therefore request that the issue be addressed as soon as possible.

We would like to remind you that these servers are running in a production environment and that the proper functioning of local backups is one of the most important aspects of system security and reliability.

Thank you for your attention.

I urgently contacted José, and he replied that an update is planned within a few hours to fix this problem.

I would also like to report an issue with the email notification that is supposed to confirm whether the backup has completed successfully.

The email does not always arrive, and when it does, it does not specify whether all accounts and websites were backed up successfully. It also does not clearly indicate whether the entire backup process completed without errors or which accounts, if any, failed to be backed up.

I have extensively worked with Google Gemini to figure the cause of the bug and in my isolated instance I have found the following issue.

The backup staging works correctly but the tar compression script bombs because of a slash concatenation in the hardcoded python script that is apparently encrypted closed source code. With standard command line I was able to bypass the faulty path and execute the compression as per usual.

Man! This took a while. After one week of daily rolling failed backups and having to pause quota system in an attempt to find the problem through process of elimination and avoid user account choking up - I would like to believe I am somewhat wiser.

Good luck to everyone!

PS  The scipt for compression. Adapt paths as needed

Code: [Select]

for dir in /backup/staging/*; do
    username=${dir#.backup_temp}
    if [ -d "$dir" ] && [ ! -z "$username" ]; then
        echo "Archiving account: $username"
        tar -pczf /backups/full/Wednesday/accounts/${username}.tar.gz -C "$dir" .
    fi
done

The fix was implemented in the latest update.33

I'm observing a few successive CWP minor update versions in matter of 10 days. I'm ready to let it run autonomously overnight. Hopefully this is the last time I have to stay awake after 2am.

Perhaps a beta / stable / LTS differentiation in the future can prove helpful to unsolicited coding errors that are caught before making it to production.

There is a beta vs stable track if you prefer the immediate security benefits or the 2 weeks of testing before the updates get pushed out to all users. Your choice of which track.

I have confirmed that all my instances are set for stable channel updates.

My concern is the erroneous programming that slipped through the cracks for a working feature that worked for months without fail. This effectively deems the emails of a successful backup as null and void and practically unbelievable since it is now evident that there is no checking that the compressed files have landed in the relevant path for each day of a daily backup. This is the local backup feature and technically should be the absolute robust and most reliable option of the lot as there is no external variables to take into account.

Unlike others, I am able to comprehend your stand in the marketplace for an extremely cheap (aspiring to be enterprise-level) web and mail control panel. Perhaps a good and working system starts with absolutely reliable local backups. The onus then remains on the SysAdmin to ship the completed backups to another location to prevent the machine from choking up.

CWPpro version: 0.9.8.1235

Backup staging folder not flushed after compressed files created in the respective daily backup folder.