• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Issue schedule backups dont start

alfonsocs_

New Pleskian
The schedule Backup to FTP or local server does not start. If I do manually it works fine.
I do not see the backup log file being created neither I dont see anything related to the scheduled backup in the log file /var/log/plesk/PMM/pmmcli.log.
when activating the task the message is correct : "the backup job has been scheduled"
 
Anything in the panel.log? If not try to enable debug and check if there are any hints:

Maybe also worth checking:
 
It not show anything neither with the debug I dont understand it.

The scheduled backup is at 9:00AM

MariaDB [psa]> select obj_id, obj_type, last, period, active, backup_time from BackupsScheduled where obj_type='server';
+--------+----------+---------------------+--------+--------+-------------+
| obj_id | obj_type | last | period | active | backup_time |
+--------+----------+---------------------+--------+--------+-------------+
| 1 | server | 0000-00-00 00:00:00 | 86400 | true | 09:00:00 |
+--------+----------+---------------------+--------+--------+-------------+
1 row in set (0.00 sec)

or also We can see here:

MariaDB [psa]> select * from BackupsScheduled\G
*************************** 1. row ***************************
id: 1
obj_id: 1
obj_type: server
repository: ext
last: 0000-00-00 00:00:00
period: 86400
active: true
processed: false
rotation: 4
prefix:
email: [email protected]
split_size: 0
suspend: false
with_content: true
backup_day: 0
backup_time: 09:00:00
content_type: backup_content_all_at_domain
full_backup_period: 2592000
mssql_native_backup: 1
backupExcludeFilesId: 1
backupExcludeLogs: 1
remoteStorage: ftp


but the last information of debug is at 08:53:

[2020-03-13 08:53:22.056] DEBUG [dbquery] [93] END: 0.00004 sec
[2020-03-13 08:53:22.056] DEBUG [dbquery] [94] SQL: SELECT `longtaskparams`.* FROM `longtaskparams` WHERE (`task_id` = '219')
[2020-03-13 08:53:22.056] DEBUG [dbquery] [94] END: 0.00004 sec
[2020-03-13 08:53:22.056] DEBUG [dbquery] [95] SQL: SELECT `longtaskparams`.* FROM `longtaskparams` WHERE (`task_id` = '220')
[2020-03-13 08:53:22.056] DEBUG [dbquery] [95] END: 0.00004 sec
root@eur:~

I'm still investigating but I'm lost with this ..
 
You can disable and then enable again the scheduled backup, should that not work try:

Code:
# plesk db "update BackupsScheduled set last = '2020-01-01 00:00:01' where id = 1;"

Then the backups should start working on scheduled basis
 
Another trouble source can be the number of concurrent backups. If this is set to "1" for example, a backup might not start for a long while, because other backups that have not finished block the start of the next one.
 
I think I have the solution, I tell you what I did,

I reset the time of de last backup but nothing dont works:

Code:
MariaDB [psa]> update BackupsScheduled set last = '2020-01-01 00:00:01' where id = 1;

Also disable and then enable again the scheduled backup and nothing.

I reboot the linux server and nothing.

Testing different configurations uncheck Run scheduled backup processes with low priority and It works now !

I have tried to configure two backups at different times and have completed them. If I check again run scheduled backup processes with low priority and it doesn't execute them. Somehow with low priority it does not launch the backups. Is a bug ? I understand that if this option exists it is to be able to configure the priority of the backups.

I'll keep the system under observation but it seems to work.

Thank you all for your advices.
 
Very interesting solution! Last year on a server under heavy load we saw a similar issue: Backups did not start at the scheduled time any more, but many hours later. So maybe there is general algorithm in Plesk that when "low priority" is selected, it does not work as "limit CPU consumption" but as "wait until enough CPU time becomes availble". In that case the option should be re-labelled.
 
Now in Obsidian 18.0.26:
Added the ability to set priority for backup processes. Go to Tools & Settings > Backup Manager (under “Tools & Resources”), click “Settings” and look for the “Run scheduled backup processes with low priority” and “Run all backup processes with low priority” options. (PPPM-10734)
 
I'm running Obsidian 18.0.29 update #2 on CentOS 6.10 (Final)

With both “Run scheduled backup processes with low priority” and “Run all backup processes with low priority” enabled all backups fail to create.

The stderr log file in ../usr/local/psa/PMM/sessions/2020-08-24-111515.033

says

ionice: ioprio_set failed: Operation not permitted

With both options disabled backups will then create and run but only if I remove any previous backups from ../var/lib/psa/dumps/domains/ or ../var/lib/psa/dumps/clients/ first

Can this be looked at again please? I can share the output from the pmmcli.log relating to this if it will help.
 
The command ionice might not be available in some environments, specificially virtual host instances like OpenVZ.
 
CentOS Linux 7.8.2003 (Core)
Plesk Obsidian
Version 18.0.29 Update #2, last updated on Aug 20, 2020 03:20 AM

I am also experiencing a similar issue in that scheduled backups are not running but I can run a backup manually to both local & Google drive.

Like alfonsocs I tried everything he did including unticking run as low priority but unable to get it to run.

The problem seemed to start when Plesk thought that Google drive didn't have enough space for a full backup even though it did & there is also a problem of it
taking a long time to go into backup manager about 10-12 seconds & its not a problem being unable to contact external storage.

I haven't tried removing all backups from ../var/lib/psa/dumps/domains/ or ../var/lib/psa/dumps/clients/

Cron is definitely running but I'm not seeing any log errors or I'm not looking in the right place.
 
Back
Top