Issue Scheduled Backup: Not working anymore and access rights issues since 18.0.66

[zamkc]

Server operating system version

Ubuntu 22.04

Plesk version and microupdate number

18.0.66 #1

Since the update to 18.0.66 (on December 18), our backups have stopped.

Initially they were still running until December 25th, but suddenly with tons of errors regarding permission denied on secondary vhosts, mails etc. - Same problem as descriped here: Issue - Issues with making backups but also for various “Subscription” and “Mail”.

plesk repair fs

... did not give any errors.

The user rights for all vhost directorys and mailnames match, as well as for DUMP_D (0750 psaadm.psaadm) and DUMP_D_TMP (1777 root.root)

Then suddenly there were no more backups, as if the scheduled job was not running.
We were able to determine that for some unknown reason the entry in /etc/cron.d/plesk-backup-manager-task no longer existed, the file was empty.
The file was apparently last modified at the time of the update. This means that it was empty after the update.
I have re-entered the following:

5,20,35,50 * * * * root [ -x /opt/psa/admin/sbin/backupmng ] && /opt/psa/admin/sbin/backupmng >/dev/null 2>&1

Since then, the Backup Manager only outputs this at the runtime point of the scheduled backup:
The backup MON X, 20XX XX:XX AM was not created.

backup.log for the respective entry is empty, 0 bytes.

We have also reinstalled plesk-backup-utilities and run the following command:

plesk repair installation

... without any errors - no change.

The entries and structure of db.BackupsScheduled are correct (and change correctly).

Expand/Collapse Block

 `id`
 `obj_id`
 `obj_type`
 `repository`
 `last`
 `period`
 `active`
 `processed`
 `rotation`
 `prefix`
 `email`
 `split_size`
 `suspend`
 `with_content`
 `backup_day`
 `backup_time`
 `content_type`
 `full_backup_period`
 `mssql_native_backup`
 `backupExcludeFilesId`
 `backupExcludeLogs`
 `remoteStorage`
 `exclude_mail`
 `exclude_user_files`
 `exclude_user_databases`

By the way, manual backup still works (but still with the permission denied problems).

 

[zamkc]

Small update:

I reinstalled plesk-backup-utilities (again) and suddenly at least the scheduled backup is running again, BUT the rights problem with the warnings for subscriptions and mails still exists. As I said, the permissions for all the folders fit, which “repair fs” confirms.

 

[Sebahat.hadzhi]

Hello, @zamkc. Could you please provide an example of the warning messages you get during the backup generation?

 

[zamkc]

Hello, @zamkc. Could you please provide an example of the warning messages you get during the backup generation?

Sure

Warning: Subscription "domain.xx"
Unable to back up files from /var/www/vhosts/domain.xx owned by system user. Error: Failed to create archive: backup_user-data_2501100220.tar    0
Repository error: Unable to pack /var/www/vhosts/domain.xx: /usr/lib/plesk-9.0/sw-tar: /mnt/backup_tmp/pmm-ru-ca-includes-WXWYgm: Cannot stat: Permission denied
/usr/lib/plesk-9.0/sw-tar: Error is not recoverable: exiting now

Warning: Mail "domain.xx"
Unable to back up mail messages. Error: Failed to create archive: backup_domainmail_2501100220.tar    0
Repository error: Unable to pack /var/qmail/mailnames/domain.xx: /usr/lib/plesk-9.0/sw-tar: /mnt/backup_tmp/pmm-ru-ca-includes-P57STO: Cannot stat: Permission denied
/usr/lib/plesk-9.0/sw-tar: Error is not recoverable: exiting now

etc.

As already described, the rights match: Mailnames all have popuser, domains have their subscription owners, backup_tmp has root and 1777, backup_dump has psaadm and 0750.

There are also files in backup_dumps and backup_tmp. I was able to observe live during the backup that the temporary directory from the error log “pmm-ru-ca-includes-WXWYgm” was at least created and after running the backup the temp directories are also gone again.

The only directory that correctly creates a backup is that of the main domain. We have several subscriptions and domains + sub-domains and so far this has worked without the permission error messages until the update to 18.0.66.
But it is also problematic that no backup is created for the mails of the main domain which also throws the permission error.

By the way, we installed patch #2 yesterday, but there was nothing relevant regarding backups and the scheduled backup tonight threw the permission errors again.

 

[Sebahat.hadzhi]

Thank you. In most cases, that issue is caused because DUMP_D and DUMP_TMP_D are set to the same folder. However, from what I understand you have them set to different folders. The permissions of backup_tmp are correct, but for backup_dump the recommendation is 755. Thus, just for the sake of testing would you mind changing them to 755?

 

[zamkc]

Hi,

In any case, the two DUMP directories are defined differently in psa.conf:

# Backups directory
DUMP_D /mnt/backup_dumps
# Backups temporary directory. DUMP_TMP_D should not be inside of (or equal to) DUMP_D.
DUMP_TMP_D /mnt/backup_tmp

I have found the solution to set the rights for DUMP_D to 750 in several places (Stackoverflow etc.). But I have now set it to 755 and will observe this during the next backup.

 

[zamkc]

The backup Jan 15, 2025 02:20 AM was not created.

This is the latest error (backup.log)
[2025-01-15 04:03:44.156|1374376] INFO: Flush cashed data
[2025-01-15 04:03:44.257|1374376] INFO: Finish upload: 623126665728 bytes transferred
[2025-01-15 04:03:44.359|1374376] INFO: Ftp init url ftps://*******.your-storagebox.de/
[2025-01-15 04:03:44.416|1374376] INFO: ExportError Export error: The size of the volume backup_2501150220.tar 623126665728 does not match the expected one 623126664704. The remote backup may not be restored. [common/plesk-utils/PMM/pmm-ras/main.cpp:ExportError]
[2025-01-15 04:03:44.416|1374376] INFO: pmm-ras finished. Exit code: 131

Btw. i already tried to modify panel.ini with
[pmm]
ftpForbidReuseConnection = 1
ftpMaxTlsVersion = 12

 

[zamkc]

Also this:
pmm-ras failed (Error code = 1): Repository error: Failed to read backup backup_2501150220.tar: Import error: Unable to find the archive metadata. The archive is not a valid Plesk backup or has been created in an unsupported Plesk version

Is it safe to clear the dump and tmp folders for a "fresh backup start"?

 

[Sebahat.hadzhi]

There shouldn't be an issue to remove the backup files from the dump/tmp folder. Do you happen to have any website plugins or cron jobs that are configured to regularly remove/update data and more specifically at the time of the backup process?

 

[zamkc]

There shouldn't be an issue to remove the backup files from the dump/tmp folder. Do you happen to have any website plugins or cron jobs that are configured to regularly remove/update data and more specifically at the time of the backup process?

Partially. There are of course jobs that process data in the databases, but the cleanup jobs for files run before the backup. However, these only affect temporary files from directories that we exclude in the backup. But such changes should not be a problem in the backup, because /qmail/mailnames/ also changes permanently, even during a backup process.
But as mentioned in the opening post, this was not a problem until the update in December. Since then, as I said, it first started that backups were no longer complete according to the log, then the scheduled backup no longer ran automatically because the entry in cron had 0 bytes and with the customization attempts everything apparently stops completely. I do not understand this. I have changed the DUMP_D_TMP in the config to /tmp instead of /mnt/backup_tmp and will observe this in the next cycle - I have read that this helped some people. But that can't be it. Problem is, the disk with /tmp is not the biggest to store temp data for backups, so we had outsourced that.

 

[zamkc]

Ok, after I changed DUMP_D_TMP to /tmp (root path), the backup works again, including all previously missing content.
What is the reason for this? The previous directory had the same rights (1777) and owner (root).

 

[mow]

Ok, after I changed DUMP_D_TMP to /tmp (root path), the backup works again, including all previously missing content.
What is the reason for this? The previous directory had the same rights (1777) and owner (root).

What are the permissions of /mnt?

 

[zamkc]

What are the permissions of /mnt?

/mnt/backup_tmp was an example to not expose our real path structure.

It's more like
/var/www/something/backup_tmp/

/var -> root:root 755 (of course)
/www -> root:root 755 (of course)
/something/ -> systemuser:systemuser 710
/backup_tmp -> root:root 1777

All created files in backup_tmp and backup_dump were created by root, so it seems that the backup process is running as root anyway. And as mentioned, everything was running smoothly until the update.

 

[mow]

All created files in backup_tmp and backup_dump were created by root, so it seems that the backup process is running as root anyway.

Some subprocess might be dropping privileges, though. And that would be blocked by the --- for "other".

 

[zamkc]

Some subprocess might be dropping privileges, though. And that would be blocked by the --- for "other".

Mh, maybe.

Unfortunately, I cannot simply change the owner of the intermediate directory to root, as this would have other consequences. ^^
I also won't use symlinks because I don't know how the Plesk backup manager reacts to the rights checks here.

I will try to set a mount from /tmp/backup to the directories, with the necessary rights. As mentioned, the problem is that the main disk does not always have enough free space for the temp file creation of the backups.