Errors after backing up account

[Alan_SP]

I upgraded my server (yum upgrade) and also upgraded Plesk to the latest (from 10.1.1 to 10.4.4 with latest micropatches).

There is one bug, with time zone. I set server's time zone to GMT +2 Europe/Vienna, but backup starts like server time is GMT (backup starts two hours later). But, with this bug I could cope, manually setting backup time two hours earlier then I want it to start.

But, there's a problem that worries me.

I have two accounts and for one, bigger (backup size is about 2GB) I always receive email that there was errror:

______________________
Backup task finished.

Task was created by with guid (dee9005e-8d34-45ec-8006-1c403eff3764)


Creation date is: 2012-May-26 05:43:02
Task status is: error

Dump full name is: dnevni-account_xxxxxxxxxxxxxxx_1205260543.tar
_______________________
File is created, I see it. Backup is done using FTP repository. But, now I'm not sure if there's serious error, could I restore this backup, or is this just a waste of time. When I was on 10.1.1 backup task was finishing without errors, with similar size.

What is happening and why? Are backing up functional and reliable with Plesk 10.4.4?

 

[IgorG]

Try to find a reason of this error in backup logs with help of article http://kb.parallels.com/en/111283 (Plesk Backup Manager section)

 

[Alan_SP]

This is what's in the logs:

[21852]: 01:13:02 INFO ------------------------------------------------------------
[21852]: 01:13:02 INFO Migration status reporting initialized.
[21852]: 01:13:02 INFO Status file: /usr/local/psa/PMM/sessions/2012-05-28-031301.910/dump-status.xml
[21852]: 01:13:02 INFO ------------------------------------------------------------
[21852]: 01:16:04 ERROR 89e0b936-bc81-4a8a-8714-196b241281bc Unable to execute SQL: MySQL server has gone away
[21852]: 01:17:04 ERROR 287a4900-52e9-41a8-860b-9af6756b8aa6 Unable to execute SQL: MySQL server has gone away
[21852]: 01:24:14 ERROR b49d5c4b-9058-4c13-8b35-773ec8986f89 Unable to execute SQL: MySQL server has gone away
[21852]: 01:24:57 ERROR 9a231b2c-236e-49ca-8fa5-02741ebda9b0 Unable to execute SQL: MySQL server has gone away

== STDERR ====================
1+0 records in
1+0 records out
31457280 bytes (31 MB) copied, 0.23562 seconds, 134 MB/s
DBD::mysql::st execute failed: MySQL server has gone away at /usr/local/psa/PMM/agents/shared/Db/DbiBackend.pm line 66.
DBD::mysql::st execute failed: MySQL server has gone away at /usr/local/psa/PMM/agents/shared/Db/DbiBackend.pm line 66.
DBD::mysql::st execute failed: MySQL server has gone away at /usr/local/psa/PMM/agents/shared/Db/DbiBackend.pm line 66.
/bin/tar: logs/access_log: file changed as we read it
DBD::mysql::st execute failed: MySQL server has gone away at /usr/local/psa/PMM/agents/shared/Db/DbiBackend.pm line 66.

==============================

I see that mysqlo server has gone away, but I don't see restarts of mysql server. At the moment it is the latest from atomic, 5.5.24. When I was on 5.1.x, there was no this errors (still has some logs from that time).

Is it really failed to make dump of database, or not? Is there a way that I could test backup without actually restoring it?

 

[IgorG]

Increase the 'wait_timeout' in '/etc/my.cnf' and restart mysql.

 

[Alan_SP]

Ok, thanks.

It was 20, now I'm trying with 120, to see will it solve this problem.

EDIT: It wasn't enough, trying with 360.

Strange thing is, now backup started when I scheduled it, i.e. not two hours later, as it was starting for days. Very strange, like changing this setting in mysql influenced server time.