Hello Ed,

Thank you for reaching out to us. I understand how important it is to get your website restored smoothly, and I’m here to help.

The error message you’ve provided indicates that the database user account being used for the restore process is missing specific privileges, such as SUPER or SET_USER_ID. These privileges are sometimes required for certain database operations, especially when dealing with advanced backup and restore features.

Here are some steps you can take to resolve this:

1. Check Database User Privileges:
   • Log in to your hosting provider’s control panel (e.g., cPanel or phpMyAdmin).
   • Navigate to the database user settings and ensure the user assigned to the database has all necessary privileges.
2. Contact Your Hosting Provider:
   If you don’t have the option to modify the database user privileges, contact your hosting provider. Share the error message with them, as they may need to temporarily grant the required SUPER or SET_USER_ID privileges to complete the restore.
3. Alternative Restore Methods:
   If modifying the privileges isn’t possible, try restoring your site using an alternative method:
   • Manual Restore: Extract the database file from your backup and import it manually using phpMyAdmin or a similar tool.
   • Command Line Restore: If you have SSH access, use a command-line tool like mysql to import the database.

We’re happy to help, please keep us updated!

– Brad

Hi Ed,

It’s pretty common to only have one user assigned to your websites database.  You can find the assigned user information in your websites wp-config.php file.

You can access the file through your hosting panels file manager or FTP, and also by using a plugin like Advanced File Manager for WordPress.

Once you’ve accessed wp-config.php scroll down a bit to the Database Settings section and look for the user name under /**Database username */.

I hope this helps!

Hi Ed,

It’s possible Total Upkeep performed an automated backup and that would be based on your configuration. Some questions for you:

Did you perform any manual restore operations using Total Upkeep recently, or have you scheduled automatic backups/restores?

Is the missing page a newer addition to your website compared to the rest of the content you see now?

When you checked the logs, was there any indication of changes or actions performed around the time you noticed the issue? Your last backup log could possibly have something for us to review.

If we can get information it will help narrow down if Total Upkeep may have restored the site or if another factor caused the issue. Thanks Ed!

Thanks for your detailed explanation, yes, it was very helpful.

One possible explanation for Total Upkeep not logging your restore could be an automatic restore misfire. If Total Upkeep is set to auto-restore upon critical errors, it might have reverted to an earlier state without generating a standard restore log.  Look for errors like PHP or plugin compatibility issues around Dec 15–20, which might have triggered this.

You can try to find more information on what happened to the Nov 29 changes by checking the Nov 25 backup.

• Since the Nov 25 backup pre-dates your Nov 29 changes:
  • Extract the backup to a staging site.
  • Compare the database entries and media files from Nov 25 with your current live site.
• If your Nov 29 changes are not there, the data might not have been properly saved in the database originally.

You also mentioned that DreamHost performed an automatic restore for you. The mismatch in media file structure and database entries suggests an incomplete restore occurred—possibly external to Total Upkeep. The restoration by DreamHost may have compounded this, especially if the database and file system were restored independently without synchronization.

Lastly, the PHP version change between Nov 25 and Dec 2 could have caused instability, particularly with plugins or themes. A critical error during this period may have prompted an unnoticed auto-restore.

Suggestions for moving forward:

Analyze Total Upkeep logs thoroughly. Look for indications of critical errors or auto-restore attempts, even if standard restore logs aren’t visible. Check the archive_date.log files for discrepancies.

Examine server logs around Nov 25–Dec 20 for PHP errors that might align with the timing of the auto-restore. Since the Nov 25 backup pre-dates any potential issues, you could restore it to a staging environment to verify its content and ensure the missing page is there. Then, you can recreate subsequent changes.

Recovering the Nov 29 additions to your site might be possible but you will need to download and review your Dec 2 and Dec 9 backups, especially the database:

• Use tools like phpMyAdmin or a database viewer to search for:
  • The missing page title in the wp_posts table.
  • Media references (e.g., image file names) in the wp_postmeta or wp_posts tables.
• Confirm if your Nov 29 changes exist in these backups.

From there look for Auto Restore or Error logs:

• Investigate if Total Upkeep’s auto-restore reverted to the Dec 2 backup or earlier due to an error.
• Check server error logs for PHP, plugin, or WordPress errors around Dec 2–20, particularly issues with database writes.

If the Nov 29 page data is missing from all backups you’ll need to use the media files already in the system to manually rebuild the page.  Use any draft, autosave, or revisions available in WordPress for the homepage and menu changes.

Moving forward you might also want to adjust your Total Upkeep settings. Disable Auto-Restore on Minor Changes if you suspect this feature caused unintended rollbacks, and also keep Dreamhost aligned. Ensure they perform synchronized restores for both the database and file system to prevent mismatched states.

Thanks Ed! I hope this helps with your efforts!  Let us know if we can assist you further.