I changed the scheduled date for a monthly backup and it didn't start

[SacAutos]

My server is CentOS 5.9. The plesk install has been upgraded a few times and is currently at 11.5.30/MU12.

I have a monthly backup that I run on the server. Earlier this month I updated the scheduled date for the backup to run to the evening of the 18th so it wouldn't interfere with daily operations. The backup did not run. Until I "upgraded" from 11.0.9 the backups ran when they were supposed to. I have attached a screenshot of the settings I've used.

Can I get an explanation or some assistance on what I can do to get my monthly backup to run when it's supposed to run?

Thank you.

 

[IgorG]

Scheduled backups on Plesk works as follows:

- schedule of running backupmng utility is defined in /etc/cron.d/plesk-backup-manager-task file (Once every 15 minutes. On each Plesk server specific moment chosen randomly)
- backupmng checks task records in psa.BackupsScheduled table and start them if they are exists.

So, check that you have corresponding record in psa.BackupsScheduled table first.

 

[SacAutos]

Everything looks "normal" to me. (I abbreviated some of the MySQL greeting for brevity...)

# mysql -uadmin -p`cat /etc/psa/.psa.shadow`
Welcome to the MySQL monitor. Commands end with ; or \g.
Server version: 5.0.95 Source distribution
mysql> use psa;
Database changed
mysql> select * from BackupsScheduled order by backup_day DESC limit 1;
+----+--------+----------+------------+---------------------+---------+--------+-----------+----------+---------+-------------------+------------+---------+--------------+------------+-------------+---------------------------+
| id | obj_id | obj_type | repository | last | period | active | processed | rotation | prefix | email | split_size | suspend | with_content | backup_day | backup_time | content_type |
+----+--------+----------+------------+---------------------+---------+--------+-----------+----------+---------+-------------------+------------+---------+--------------+------------+-------------+---------------------------+
| 15 | 2 | client | ftp | 2013-08-02 08:00:58 | 2592000 | true | false | 1 | monthly | [email protected] | 0 | false | true | 18 | 21:30:00 | backup_content_vhost_only |
+----+--------+----------+------------+---------------------+---------+--------+-----------+----------+---------+-------------------+------------+---------+--------------+------------+-------------+---------------------------+
1 row in set (0.00 sec)

mysql>quit;

There were other entries that pre-existed and are working properly so I crafted my query to exclude them. See anything unusual here? The 2nd of August was the last time the backup ran. (Why it ran that day is the subject of another post I've made - let's keep ourselves focused on the issue I've reported in this thread.)

 

[SacAutos]

I re-read my post this morning and I realized that it's possible that I didn't make it clear what kind of backup I was running. The backup is of a customer account. The customer has about 40 domains (I suppose we call them subscriptions now) in it. The backup is intended to gather all vhost content and databases but no email. The tar file is supposed to go to the personal FTP server defined for the account.

I hope that this is helpful in understanding the problem.

 

[SacAutos]

Any help??

 

[GianniS]

i have the same problem, im in plesk 11.5.30 and automatic backup was stopped to 30/08/2013.

 

[vkolotov]

Everything looks "normal" to me. (I abbreviated some of the MySQL greeting for brevity...)

# mysql -uadmin -p`cat /etc/psa/.psa.shadow`
Welcome to the MySQL monitor. Commands end with ; or \g.
Server version: 5.0.95 Source distribution
mysql> use psa;
Database changed
mysql> select * from BackupsScheduled order by backup_day DESC limit 1;
+----+--------+----------+------------+---------------------+---------+--------+-----------+----------+---------+-------------------+------------+---------+--------------+------------+-------------+---------------------------+
| id | obj_id | obj_type | repository | last | period | active | processed | rotation | prefix | email | split_size | suspend | with_content | backup_day | backup_time | content_type |
+----+--------+----------+------------+---------------------+---------+--------+-----------+----------+---------+-------------------+------------+---------+--------------+------------+-------------+---------------------------+
| 15 | 2 | client | ftp | 2013-08-02 08:00:58 | 2592000 | true | false | 1 | monthly | [email protected] | 0 | false | true | 18 | 21:30:00 | backup_content_vhost_only |
+----+--------+----------+------------+---------------------+---------+--------+-----------+----------+---------+-------------------+------------+---------+--------------+------------+-------------+---------------------------+
1 row in set (0.00 sec)

mysql>quit;

There were other entries that pre-existed and are working properly so I crafted my query to exclude them. See anything unusual here? The 2nd of August was the last time the backup ran. (Why it ran that day is the subject of another post I've made - let's keep ourselves focused on the issue I've reported in this thread.)

I think the reason of problem is that you edit backup_day to 18, but last backup was made 2013-08-02.
Pmmcli daemon checks that your backup interval = 1 month, but last backup was made about 2 weeks ago. So, daemon haven't run backup task. 2 weeks < 1 months.
Next task will run 18.09.2013

 

[SacAutos]

You're pretty close. I actually paid for and submitted a support ticket on this. After three weeks, it was determined that there was a bug in the process. The work-around is to manually update the database by removing the row from the BackupsScheduled table and rescheduling the backup on the date desired. Not exactly user-friendly but it will work. Notice of this has been passed back to engineering. Maybe we'll see a fix some day.

 

[vkolotov]

You want such expected result if you change backup_day: last run date must be deleted from database.
Or problem in something else?

 

[SacAutos]

When I first reported this via a support ticket, I lost a couple of weeks because of confusion over the exact issue. Let me summarize the problem once again:

I have a customer (let's call them FredCo) that has a bunch of websites, one for each of their stores. I've created a "Customer" entry in Plesk and subscriptions for each of their websites within the FredCo customer. Because FredCo gets a lot of business on the weekend, I want at all costs to avoid any extra load on the server during that time. So I scheduled their complete Customer backup like this:

From the main page, click on Customers -> Open in Control Panel for "FredCo"
On the new window, click on the Account Tab -> Backup My Account and Websites -> Scheduled Backup Settings

At this point I define the backup to be performed monthly on a non-busy day at 15 minutes past midnight and to send the files to a personal FTP server. (What good is doing a backup if the server holding it goes down??)

As I previously wrote, until recently I could log in monthly and adjust the backup day to one where I have low activity. Now this behavior no longer works. Instead, it appears that my monthly backups happen every 28 days. In my case, this happens to be a bad day because it coincides with the weekly backup that is performed for the subscriptions. The big backup gets pushed off until later in the morning and affects operations during normal business hours. Not good!

Because of the mysterious software change, even though I changed the backup day, the backup still ran whenever it pleased. So I've lost control over my server. Thus I submitted a ticket. Now I have a work-around so at least I can get control of the processing again. It's not optimal for me but at least I have a way to keep running my backups when I want them to run. The best case is for a software enhancement that gives me control over the monthly cycle via the control panel. Hopefully that will arrive sooner than later.

 

[vkolotov]

You're pretty close. I actually paid for and submitted a support ticket on this. After three weeks, it was determined that there was a bug in the process. The work-around is to manually update the database by removing the row from the BackupsScheduled table and rescheduling the backup on the date desired. Not exactly user-friendly but it will work. Notice of this has been passed back to engineering. Maybe we'll see a fix some day.

Can you write psa.backupsschedulled table before and after editing. Maybe it will be more clear for me.
I don't understand expected result, sorry...

 

[RuslanT]

Hello, SacAutos.
The issue was confirmed (internal id is TP: 143321) - if backup time rescheduled forward than next backup is performed at last+interval time. All further backup tasks will be performed in the scheduled time (If have not been changed before the scheduled time).