• Hi, Pleskians! We are running a UX testing of our upcoming product intended for server management and monitoring.
    We would like to invite you to have a call with us and have some fun checking our prototype. The agenda is pretty simple - we bring new design and some scenarios that you need to walk through and succeed. We will be watching and taking insights for further development of the design.
    If you would like to participate, please use this link to book a meeting. We will sent the link to the clickable prototype at the meeting.
  • (Plesk for Windows):
    MySQL Connector/ODBC 3.51, 5.1, and 5.3 are no longer shipped with Plesk because they have reached end of life. MariaDB Connector/ODBC 64-bit 3.2.4 is now used instead.
  • Our UX team believes in the in the power of direct feedback and would like to invite you to participate in interviews, tests, and surveys.
    To stay in the loop and never miss an opportunity to share your thoughts, please subscribe to our UX research program. If you were previously part of the Plesk UX research program, please re-subscribe to continue receiving our invitations.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.

Errors after backing up account

Alan_SP

Basic Pleskian
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?
 
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?
 
Increase the 'wait_timeout' in '/etc/my.cnf' and restart mysql.
 
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.
 
Last edited:
Back
Top