Cannot back up virtual server


I want to move my virtual server to another server. So I use backup feature to backup my virtual server. However it show error below: Please help. Btw, is there any way to move a virtual host directly to another server. I have root account and both server use custom port (different with 22). Do I need to delete the existed virtual server (I created the same one there) in the destination server?

Thanks, Giang Anh



Howdy -- hmm, what is the output of these command:

rpm -qa | grep mysql
rpm -qa | grep maria

Also, we'd be happy to go over your migration question, could you open a new request for that though? Thanks!


[root@jreplay1 ~]# rpm -qa | grep mysql
[root@jreplay1 ~]# rpm -qa | grep maria
[root@jreplay1 ~]#

Ah, it looks like you have a non-standard MySQL version there.

There may have been an issue during the upgrade process that hasn't given out all the necessary permissions to all the system tables. Or some of the tables may have become corrupted in the process.

We also saw a similar compatibility issue here:

You may run into problems with using software not included with your distro. We highly recommend using the software included with your distribution.

Unfortunately, Virtualmin doesn't really support that MySQL version yet, not everything will work properly. Problems can also occur during the upgrade process to a difference MySQL version.

I did some Googling on the issue you're experiencing, and found this URL here:

However, we're really not able to support non-standard software, I'd highly recommend using the MySQL version that comes with your distribution.

I'm very sorry, but we're unfortunately not familiar with the process of upgrading to that MySQL version.

We've only ever tested the one included with CentOS.

There is very likely a solution, we just don't know what it is.

If you wish to continue using that MySQL version, my suggestion would be to Google the error you're seeing, and see if others have come up with a solution to that problem.

This is the error I would Google:

mysqldump: Couldn't execute 'show events': Cannot proceed because system tables
     used by Event Scheduler were found damaged at server start (1577)

I see a lot of hits when Googling that, maybe one of those will correct your problem.

Also, you could ask in the MySQL community, as they may have an idea what that problem is. Another alternative is to ask the people who maintain the repository that MySQL package came from, as they may be familiar with that problem.


How about I downgrade the MySQL version?

Thanks, Giang Anh

Yeah, using the CentOS MySQL version is the best long-term solution if you intend to continue using CentOS for some of your domains (if not, I have another idea below).

We unfortunately don't have experience in switching from your current MySQL version to the CentOS one, so we're not able to provide steps for how to make that work.

You may want to test the process on a test server prior to making the change on your production server, just to verify that there aren't any issues that arise.

This here lists some of the complications that could arise in downgrading from 5.6 to 5.5:

Out of curiosity, how many databases do you currently have?

And are you trying to move all domains to another server?

If you don't have many domains, and you're looking to migrate all your domains to another system, I'm wondering if maybe we'd have better luck manually migrating the databases to the new server, rather than trying to change the MySQL version.


I have about 10 databases but I only want to migrating one domain to new server. Since I don't have experience to migrate the virtual server, I have to use Virtualmin one. Downgrade the MySQL version seems complicated and risky for me.

Thanks, Giang Anh

Yeah, all the options are a bit complicated :-)

If you don't downgrade, you could always try the suggestions above for how to fix the problem with your current MySQL version (that is, Googling that error, and asking the MySQL community).

Without doing one of those, you won't be able to perform automated Virtualmin backups.

However, there may be another option for migrating this one Virtual Server.

You can perform a backup of the Virtual Server, but tell the backup process not to backup the MySQL data.

Then, for the domain you want to migrate, go into Edit Databases -> Manage -> Backup Database. That screen there may work to generate a manual database backup, even if the full database backup isn't working.

It will put your database data into a single text file.

If that works, then import your Virtual Server backup (which doesn't have a database) on the new server.

Then enable the MySQL feature for that domain on the new server (in Edit Virtual Server -> Enabled Features).

Create the database for that domain on the new server (in Edit Databases).

And then on the new server, go into Edit Databases -> Manage -> Execute SQL -> Import text file. That screen will allow you to import database data stored in a text file.

It is still failed:

Backup failed : SQL select user.user,user.password from user,db where db.user = user.user and (db.db = 'jplay' or db.db = 'jplay') failed : Can't open file: './mysql/user.frm' (errno: 24 - Too many open files)

And even for database backup:

Database backup failed : mysqldump failed :
mysqldump: Couldn't execute 'show events': Cannot proceed because system tables used by Event Scheduler were found damaged at server start (1577)
Scheduled backup for database left disabled.

Just to clarify, what changes did you make prior to attempting the backup again?

Okay, it unfortunately looks like the corruption in the system tables is preventing any kind of MySQL backup from working.

That leaves two options --

One, you could correct the corruption in the system tables. We don't know how to do that, but you could search for the following in Google:

Couldn't execute 'show events': Cannot proceed because system tables used by Event Scheduler were found damaged at server start (1577)

And maybe one of the people experiencing that problem has a suggestion that would work for you. You could also talk to the MySQL community about how to correct that.

Or, you could move back to the default CentOS MySQL packages. That's not without risk though, and if you do that, I'd recommend doing it on a test system first.

I think the simplest and least risky option would be to try and get MySQL 5.6 working again, though for down the road you may want to consider migrating back to the default MySQL version.

While this is outside the scope of the normal Virtualmin support we provide, and we're not familiar with the process of upgrading to MySQL 5.6 -- if you're interested in hiring us for our Professional Services, we could always log into your server and try to figure out how to resolve that corruption error you're seeing in MySQL.

I think we could do that in an hour, which would cost $125.

If we don't get it working, we wouldn't charge you anything.

We would only charge you if we're able to correct the error you're getting.

You don't have to use our Professional Services though, you're also welcome to ask in the Forums for free, as well as in the MySQL community.

Thank you andreychek. I will try to solve it followed your suggestion first. If it's not possible, I will use your service. Btw, in this server I often has extremely high CPU load as mentioned in another ticket: Is it possible if you help me to solve this as well? It's ok for me to pay more.

Thanks, Giang Anh