• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Resolved Panic! Site crashed and restoring backup fails

carlsson

Basic Pleskian
Server operating system version
Ubuntu 20.04.6 LTS
Plesk version and microupdate number
Version 18.0.60 Update #1
Short story:
The biggest (and most crucial) site on my Plesk installation have crashed. I have tried to restore a backup from yesterday morning, but it fails with "Restoration of the backup April 30, 2024 02:01 AM failed". The log is empty.

Long story:
mysite.com is a Wordpress installation, with multisite and integration to an external booking system. It's a client that sell outdoor activities and they have their peak now.

Yesterday morning I decided to do some updates on the site.
I also decided to fix some of the security measures suggested by WP toolkit.
Before the updates I manually did a backup with WP Toolkit > Backup and Restore.
After the updates I looked at the site and all looked good. However, today I was informed that the booking system doesn't work, and many pages are missing etc etc.
No panic I was thinking to myself, I have backups!

So I have tried the following:
- WP Toolkit Restore. Didn't work, it created a readable error though that started with: "WordPress database error table mysite.com.wp_blogs doesn't exist for query SELECT wp_blogs.blog_id"
- Plesk restore. Failed, I don't know why. It took an hour to restore because i have the backup stored in the cloud.

Now I am clueless and curse myself for updating… :(

My guess is that the security measures applied was the thing that broke it, I applied things that I shouldn't. Unfortunately I don't remember exactly what I applied, and Now when I enter the Security status pane I get the following errors:
An error occurred while checking the status of disabling file editing in WordPress Dashboard on 'www.mysite.com (Mysite)'.
An error occurred while checking the status of pingbacks for the WordPress installation 'www.mysite.com (Mysite)'.
An error occurred while checking the status of scripts concatenation for WordPress admin panel on 'www.mysite.com (Mysite)'.
An error occurred while checking for security keys on the WordPress installation 'www.mysite.com (Mysite)'.


I am quite sure this have to do with the database(s). But why doesn't a Plesk restore work?
At the moment I have created an index.html file that tell the customers to call, but I have no real idea of how to get the Wordpress site up and working again.

Please help!
 
Clarification:
When I restore the site with Plesk Backup Manager I was using the Sites option and choosed mysite.com.
I am currently in the process of restoring with the Database option as well, since I'm not sure if Sites take that as well.

1714554470808.png
 
So I have tried the following:
- WP Toolkit Restore. Didn't work, it created a readable error though that started with: "WordPress database error table mysite.com.wp_blogs doesn't exist for query SELECT wp_blogs.blog_id"
I remember once encountering an issues when restoring a WP Toolkit backup as well. Was to long ago to remember what the issue was exactly. I do remember that when I deleted all website files and the database the backup restore suddenly did work. (Make a backup of your broken site before trying this.)
 
I remember once encountering an issues when restoring a WP Toolkit backup as well. Was to long ago to remember what the issue was exactly. I do remember that when I deleted all website files and the database the backup restore suddenly did work. (Make a backup of your broken site before trying this.)
Thanks for the input!

Should I take that backup with WP Toolkit, Plesk or manually?
And when you say "website files", do you mean everything in the httpdocs directory?
 
Alright, one more question; If I delete the database, will WP Toolkit remember the user and password when it restores it? If not, how do I solve that?

When I'm sure about this I'll just use "Remove Database" in Plesk, no reason to use phpMyAdmin for that, right?
1714559545196.png
 
Alright, one more question; If I delete the database, will WP Toolkit remember the user and password when it restores it? If not, how do I solve that?
The password for the database user you mean? Yes, those are actually stored in the wp-config.php file of the Wordpress site. In case you want to recover the database manually you can use the database credentials (database name, database user and database users password) available in that file.

When I'm sure about this I'll just use "Remove Database" in Plesk, no reason to use phpMyAdmin for that, right?
Yes. Make a dump first (as a manual backup of the database).
 
Dump created before I did a Remove Database, then WPT> Restore, after 10 minutes I got this error:
1714560829816.png

…and then this: "WordPress installation www.mysite.com (#26) is not available for current operation because it is broken"

Something tells me the restore couldn't restore the database...?
 
The dump is 411 MB .

I created an SQL database with same name, user and pw as before and imported the dump. Now I have restarted Plesk (just in case) and I'm currently doing a restore again.
 
Alright. BTW: don't hesitate to contact Plesk support and ask them for assistance on your backup recovery if you need help :)
 
After restoration I got this:

Failed to restore site from backup​
• WordPress database error Table 'mysite_db.wp_blogs' doesn't exist for query​
• SELECT wp_blogs.blog_id​
• FROM wp_blogs​
• WHERE domain IN ( 'www.mysite.se', 'mysite.se' ) AND path = '/'​
• ORDER BY CHAR_LENGTH(domain) DESC​
• LIMIT 1​
• made by require_once('/opt/psa/admin/plib/modules/wp-toolkit/vendor/wp-cli/vendor/wp-cli/wp-cli/php/boot-fs.php'), require_once('/opt/psa/admin/plib/modules/wp-toolkit/vendor/wp-cli/vendor/wp-cli/wp-cli/php/wp-cli.php'), WP_CLI\bootstrap, WP_CLI\Bootstrap\LaunchRunner->process, WP_CLI\Runner->start, WP_CLI\Runner->load_wordpress, require('wp-settings.php'), require('wp-includes/ms-settings.php'), ms_load_current_site_and_network, get_site_by_path,​

And also this in WPT:
1714562450310.png
 
I am out of suggestions. There is something fishy going on with your database. If I had to guess I'd say the "wp_blogs" table isn't included in your database dump/backup. But it's hard for me to assess the whole situation at this point. I recommend contact Plesk support for assistance. I am not saying they are wizards, but sometimes it sure looks like they can preform magic.
 
Thank you for your help Kaspar! I have contacted Plesk and are awaiting their feedback. My feeling is that the solution is very easy for someone that knows everything about Plesk, WP, Linux and mySQL... I am obviously not that person. :rolleyes:o_O
 
Perhaps try restoring the database manually from a previous non WP Tookit dump (hopefully you dumped it from Plesk database page prior to all of this)? You can create the database manually with the same name, user, and credentials used by WP (as documented in the config file), then use the import dump command from the databases page (for that db) in Plesk.

On a side note, once you get back, take a look at the Plesk backup extensions. For critical sites, I like to use one of those (AWS, etc), and create database only backups every 4 hours, or however frequently needed and send those offsite.
 
Plesk support have helped me with this now, and it seems to work!

I wonder though, why the WPT Restore didn't work from start?

@nmdpa3 : I will definitely take a look at backup extensions, I don't want this to happen again… o_O

Thank you guys for your help, highly appreciated!
 
Awesome! Good to read your site is running again.

I wonder though, why the WPT Restore didn't work from start?
A perfectly good question for Plesk support too. Knowing why it failed it always useful and might help you to prevent similar issues in the future.
 
Followup from Plesk support since this can help future people in the same situation:

"When prefix database mismatch was generated, WP-Toolkit detected the WordPress instance as broken, because of that, the restore probably didn't work.
Plesk backup would have worked, with the option "Restore this backup despite the fact that it does not have a valid signature" checked as showed in the article that I sent before."

The article in question is here.

And yes, that is correct – I never tried that option.
 
Back
Top