Some pages wiped in database backup

Only the www.ads-software.com moderators can do moderation (plugin authors can’t)…. usually it’s because you put more than 2 URLs into the post. In that case, it’s best to leave some out, or post the details at pastebin.com and just post a link, or something like that.

I know — hopefully, they will review and approve it sometime today.

The long story short is that I ran a new restore operation using a database backup created earlier today. Again, it wiped the contents of most of the pages, although that content WAS present in the backup file (which I retained this time, along with the logs; the logs are what’s in the post awaiting moderation).

www.ads-software.com don’t allow posting of data like log files in forum posts – they’ll tell you to use something like pastebin.com instead.

If you want to share the backup archive set and other info with me, then use this form – https://updraftplus.com/ask-a-pre-sales-question/ – and mention the URL of this support topic, so that it gets forwarded to me. I can then run the same restore on test hosting. You’d also need to tell me the post ID of one specific post / page that didn’t restore.

I’m not comfortable sharing the backup data set; it would create compliance problems for me with various privacy laws because the data set contains visitor personal information.

As before, neither the backup log nor the restoration logs indicate anything that looks like an error.

If you have identified the specific post ID that contains the post that doesn’t restore, then if you go to phpMyAdmin in your web hosting control panel and run this SQL…

SELECT post_content FROM wp_posts WHERE ID=(id)

(Replace wp_ with your actual table prefix; replace (id) with the actual ID (omit the brackets)).

… then what do you get?

I am happy to provide and/or sign a data processing agreement for data protection compliance. (These state what the processor, i.e. entity handling the data, i.e. me, legally agrees to do/not do with it).

The restoration erased the post_content of seven of the site’s 11 pages. No posts were affected. When I checked immediately after restoration, either by looking via the dashboard or through phpMyAdmin, each of those pages’ post_content was empty (I have since restored them from offline copies). Other fields don’t appear to have been affected. The pages’ slug and SEO meta descriptions, for example, remained untouched, but the actual content was somehow deleted.

Presumably your posts table won’t contain any personal information, and so could be shared?

If so, do this:

1) Decompress the database backup file (the one ending in db.gz).

2) Scroll down to the first line that begins with DROP TABLE. Cut from there…

3) … until the DROP TABLE for your posts table.

Then after all the INSERT statements for the posts table, start cutting again, until the final few lines (after the last line with “End of data”).

Actually it’d be useful to have the postmeta table as well, but it’s not vital.

Then, save it, stick it in a zip file, and share it from Dropbox, Google Drive, or whatever you prefer… and share the link with me at https://updraftplus.com/ask-a-pre-sales-question/ (don’t worry about the box that says you’re confirming it’s a genuine pre-sales question – you have permission!).

So, cut out the tables other than postmeta and posts? I can do that. (The posts and pages are already public anyway.)

Can I redact the table prefix by changing it back to wp_ in the edited file? Or is that going to create an issue?

• This reply was modified 4 years ago by Ate Up With Motor.

Yes, cut out the other tables.

If you just do a search/replace to wp_ it is possible that you may corrupt something. If you must, then replace it to something of exactly the same length as before. But really, there’s no security implications in leaving it alone. If you suspect the authors of UpdraftPlus or any other plugin might desire to hack your website (for which knowing a table prefix is completely inadequate), you shouldn’t be running it; allowing us to run thousands of lines of PHP code which you haven’t audited is a few zillion times higher level of trust/access than a useful table prefix. But if it makes you feel comfortable no problem – just, as I say, to minimise the risk of damage, keep it the same length.

Fair enough. I just sent a form with a link. If you could let me know when you’ve retrieved the ZIP file, that would be great; I’ll take it down once you have.

I included a second text file that has a list of post ID numbers affected, as well as information on installed theme/plugin components, if that’s of use to you.

Thanks!

• This reply was modified 4 years ago by Ate Up With Motor.

Thank you. That worked for me… I restored, and went to edit the item with ID 12, and here it is: https://snipboard.io/fPZoEg.jpg

It’s (unsurprisingly) in the database too (this example, of course, which fetches just the first 40 characters for brevity , uses the table prefix of the existing install that I restored into, which is inconsequential):

MariaDB [updraftclone216866277]> SELECT SUBSTR(post_content, 1, 40) FROM onsxa_posts WHERE ID=12;
+------------------------------------------+
| substr(post_content, 1, 40)              |
+------------------------------------------+
| This Privacy Policy explains what person |
+------------------------------------------+
1 row in set (0.001 sec)

This increases the likelihood that something else on the site has got involved. If you’re still not enthusiastic about letting me have the complete backup set (which is your perfect right), I suppose that you could just cut out the tables that have personal data, and leave everything else? (Including providing the backup dump of the plugins, themes and uploads too – plugins and themes at least can’t have any personal data as they’re just vendor code; and uploads may or may not, but you’ll know).

N.B. I won’t be online again until Monday once today ends (I am in the UK).

P.S. I don’t know what level of access you have to the SQL server. But if you have full admin access, you can record all queries: https://stackoverflow.com/questions/303994/log-all-queries-in-mysql

If you did that on and after restore, up until the point that you’ve verified that post_content is empty, then somewhere in between will likely be the answer (the query that runs that empties the cell). The log is likely to be quite large – an amazing number of queries get run on a normal site (and hence it’s best to try to run through the procedure as quickly as possible!).

But now I remember you said you’re on shared hosting, so that’s not going to be possible (I’ll post this just in case one of your affected sites isn’t).

N.B. If you have a shared hosting account, it is likely that all your sites are using the same MySQL server, as normally it all goes onto a single server.

I have access to the access and error logs, but I don’t have privileges for that kind of granular control.

I did look at the error log, which did record several errors at the time of the restore. Two were triggered by UpdraftPlus trying to increase the maximum packet size (which returned “WordPress database error Access denied; you need (at least one of) the SUPER privilege(s) for this operation for query SET GLOBAL max_allowed_packet=33554432. The third was related to a cron job that was disrupted by the restore operation. None of those seems like they’re probably related to the missing post_content.

Based simply on circumstantial evidence, I still wonder if Disable Gutenberg is at issue. I don’t know how plausible that is from a technical standpoint, but it’s the most recently updated common plugin across the affected site, and I’m reasonably sure I’ve run a restore subsequent to other potential suspects’ most recent updates without this issue. (Disable Gutenberg was updated two days before this issue began.)

If it would help, I can send you an UpdraftClone token. This would mean with a few clicks you can clone your site onto an UpdraftClone server, and would enable working out if the web hosting environment is involved or not, which would eliminate one more possibility.

Though, of course, I have full access to UpdraftClone servers (in the same way that any other web hosting company has access to hosted sites on their servers), I would not inspect it without your explicit permission. The purpose of offering the token is so that you can see if the same happens on different hosting – if so, that would indicate it is something inside WordPress.