One of my virtual servers failed to restore.
Actually the virtual server was set up but the database did not restore.
Here is the log –
Downloading archive from Amazon S3 server …
Extracting backup archive files …
Re-creating virtual server sd5.info …
Creating administration group secdown ..
Creating administration user secdown ..
Creating aliases for administration user ..
Adding administration user to groups ..
Creating home directory ..
Creating mailbox for administration user ..
Adding new DNS zone ..
Adding to email domains list ..
Adding default mail aliases ..
Adding new virtual website ..
Adding Apache user apache to server's group ..
Performing other Apache configuration ..
Setting up scheduled Webalizer reporting ..
Setting up log file rotation ..
Creating MySQL login ..
Creating MySQL database secdown ..
Setting up spam filtering ..
Setting up virus filtering ..
Creating status monitor for website ..
Adding analytics tracking to website configuration ..
Creating Webmin user ..
Re-starting DNS server ..
Applying web server configuration ..
Re-loading Webmin ..
Saving server details ..
Restoring backup for virtual server sd5.info …
Restoring virtual server password, quota and other details ..
Updating administration password and quotas ..
Restoring Cron jobs ..
Extracting TAR file of home directory ..
Setting ownership of home directory ..
Re-creating records in DNS domain ..
Restoring Apache virtual host configuration ..
Checking restored PHP execution mode ..
.. mode FCGId OK for this system
Updating home directory in PHP configuration ..
Restoring Webalizer configuration files and Cron job ..
Restoring Logrotate configuration ..
Deleting old MySQL databases ..
Restore failed : SQL drop database `information_schema` failed : Access denied for user 'root'@'localhost' to database 'information_schema'
Any idea why this might have happened and how it can be fixed ?
Hmm, this message is an odd one:
Restore failed : SQL drop database
information_schema failed : Access denied for user ‘root’@‘localhost’ to database ‘information_schema’
It shouldn’t be trying to drop that particular database.
Do you know how this particular Virtual Server was backed up? Was that using the Virtualmin backup function?
Also, what distro/version was used when creating that backup?
Yes the backup was done with VirtualMin Pro onto my Amazon S3 server account.
Thats why I needed to get my VirtualMin Pro back up and running.
The virtual server SD5.info has been restored and when I look in the Edit Databases under the
VirtualMin tab - I see the database " information_schema".
And it gives me access to tables like CHARACTER_SETS, ENGINES, EVENTS.
This looks pretty dangerous !
My server was “rooted” a couple of weeks ago and I had to have the server software all reinstalled and then re-loaded my websites. I have only reloaded 6 of them so far as these are my main ones that I want live.
Could this access to “information_schema” be something a hacker did ?
Any idea how I sort this out ?
There is something else that also looks wrong.
When I look at my fethiye-guide.com VS and edit databases
I see this –
(I screen captured it)
As you see there are 2 databases.
Then when I select one I get the field list –
When I click on the link to go back to the database list, I can see ALL of them.
( Maybe this is normal because I am logged in as root. )
BUT there is also 2 databases extra called –
Is this normal ?
How do you know that the backups were created BEFORE the hacker gained access to your system?
But my server admin told me to backup before he did a complete system reload.
Then to reload my websites.
By restoring the websites - will that open the door for the hacker again ?
I have only restored a few of them.
Maybe I should take the “funny” behaving ones off again ?
What do you think "
If you (or your host) don’t know how and when the hacker gained access, you should assume that the backups are compromised as well. And you should also assume that the hacker probably can use the same hack again.
Typically “websites” are the weakest link (for hackers to attack). For example wordpress, joomla or drupal have lists with vulnerable extensions.