Go to the forum admin > Toolbox > Error Log.

You might haver many entries – you can ignore notices and warnings. Just look at the pink error entries. One of them will state that it is a database error. Copy and paste the details to this topic.

also sounds like vaultpress might not be really doing a full restore…  by definition a restore would be to the same state…

I think this is the error

file: /home/leeannb1/public_html/restorativenation.net/wp-content/plugins/simple-press/admin/panel-forums/support/spa-forums-save.php
line: 280
function: sp_flush_cache
error: Table ‘leeannb1_wp442.wpea_sfcache’ doesn’t exist

DELETE FROM wpea_sfcache WHERE cache_id LIKE ‘%*group’

well, it would have existed before the restore…  assuming wpea_ is the proper wp db prefix…  sounds like the restore didnt pull back all the database tables…  its a standard simple press table…

Do you know how to create a table from a sql script because we can give you one…?

Interesting; yes, I can use the script to generate, but not sure why just this one table would be missing.

As you may know, Vaultpress is a premium service made by Automatic, which is delivered as an add-on to Jetpack.  So, one would expect they are doing things “correctly” for a typical WordPress install.

Here is what they say the do, and do not back up; can you think of any reason why this table wouldn’t get picked up by the process?  I can open a ticket with Vaultpress to investigate but any additional thought you have woudl be helpful:

https://help.vaultpress.com/backups/

What does VaultPress back up?

We back up your WordPress database (any tables which begin with your WordPress table prefix and also have a unique key or a primary key). We also back up any files in your plugins, themes, and uploads folders, and select files from your WordPress root directory and your wp-content directory.

This includes all the unique and irreplaceable data in WordPress, and everything properly integrated into the WordPress installation.

We do not back up WordPress core, core file modifications, files outside these locations, database tables which don’t look like they belong to WordPress, or database tables whose rows have no unique identifier.

First the table SQL:

CREATE TABLE IF NOT EXISTS xxx_sfcache (
cache_id varchar(40) NOT NULL DEFAULT '',
cache_out bigint(6) DEFAULT NULL,
cache mediumtext,
PRIMARY KEY (cache_id))

change the ‘xxx’ for your WP table prefix of course.

No idea why it didn’t include it in the backup I am afraid. It fit’s the claimed requirements – although why there have to be any such restrictions I can see no obvious reason for.

As to JetPack being from Automattic well – all I can say is that JetPack is one of the most troublesome , problematic and conflicting plugin ever encountered and I really dislike the way it installs huge quantities of ‘things’ turned on whether you want them or not and doesn’t make it obvious how to turn them off again. Sorry – but personally I wouldn’t go near it!

I agree with you about Jetpack, but Vaultpress is by far the best and most trouble-free backup system I’ve ever used for WordPress, and I’m pretty sure I’ve tried most of them.  You can actually deactivate Jetpack once you set up Vaultpress and run just the Vaultpress plugin.

This is the first issue I’ve had with it, which is very curious as the problem happened both times I did the restore.

Thanks for the code – I’ll give it a try tomorrow!

Kelly

let us know… but obviously, we have no interaction with a backup utility…

Creating the table per your instructions solved the problem – thanks!

I’m wondering, since this table is the only one that consistently doesn’t get restored properly, and it seems like it is used in some way for caching… Is the table accessed in some special way that might make some backup systems unable to back it up properly?  You may very well be doing something correctly/within standards etc, yet perhaps it makes this table harder to back up.  I’d love to be able to explain to Vaultpress support a little more about how this table is used if it is used in a somewhat different way that might make it harder to back up successfully. Perhaps they can consider other methods to better ensure they can manage it properly.

Thanks,

Kelly

There is nothing unique to this table. Well, perhaps just the name. My guess is vault press thinks it’s some sort of traditional cache and ignores it. We use it a little different than a true cache so it’s required. A traditional cache wouldn’t need to be used for operation. So they don’t save it. For us, it’s really just another table we use for normal operations.

UPDATE – Vaultpress support has disclosed that they don’t back up any table with ‘cache’ in the name.  They are manually adjusting my backups to include it.  I submitted a request that they back up all table with the designated wordpress table prefix, since that is the best idea and it is also what they say they do on their website.  I kinda think it is bad logic to evaluate the table name and decide whether to include/exclude, so hopefully they will agree.

Kelly

okay, thanks for the update…explains some of it…

Last update; they also decided not to backup and tables with the word BACKUP in them. They told me it was in the changelog, but I suggested to them they correct this in the product info the website which is what most people are going to read.