Restoration failed

… and another interesting observation … in the boldgrid_backup directory, the index.php file and index.html file both have a size of 0. So they were not created correctly.

Hi @mhartste

Thanks for checking out Total Upkeep!

First thing, GoDaddy Managed WordPress disallows many backup plugins, and while Total Upkeep isn’t specifically mentioned in that list, you may find that the 30-day backups already included with that hosting plan meet your needs.

That being said, my suspicion is that you may not have direct access to any of your core files. That’d be a pretty normal security measure for a Managed WP plan, to keep you safe from hacks and make sure you’re always up-to-date. If that’s the case, you can still use Total Upkeep by excluding the WordPress Core files from your backup files.

When you make a backup, or set up scheduled backups, click the Custom Backup option. You’ll see the default included and excluded files and folders. Simply delete WPCORE from the includes, and add it to the excludes.

This will make sure that your Database and wp-content folder (plugins, themes, and uploads) are still backed up so you can always restore from a bad update and keep your media files safe, while letting GoDaddy manage your core files.

Thanks, Jesse, for your quick reply, and for this tip! I might be making some progress.

I tried what you suggested, and excluded WPCORE. I then found out that there are a few other files and a directory owned by root, so I excluded them also. And then the Restore worked!

Here’s what I wound up with:

Include: /wp-content
Exclude: .git,node_modules,WPCORE,/wp-content/db-error.php,/wp-content/index.php,/wp-content/mu-plugins

So …
1- is it ok to exclude all these files?
2- how about the index.php and index.html files with length 0 in boldgrid_backup — should I be concerned about them?
3- is there any way to specify these files to Exclude on the Restore instead of the Backup? I’m concerned that some day WordPress or GoDaddy will add another root file. And I will be thinking that I have weekly, good backups. But then should I need to do a Restore, I will find out that the my backups are actually unusable!

Thanks!

Mike

Hi Mike-

Sounds like progress!

1- is it ok to exclude all these files?
Yes, I think you’ll be just fine excluding these. They’re protected by the system for Managed WordPress. The whole reason they’re owned by root is so that they can prevent any unauthorized changes to them. They’re probably actually symbolic links to a protected, central set of WordPress Core files that the Managed System regularly checks and maintains.

2- index.php and index.html with 0 byte filesize?
I betting that if you take a look in the log for that backup, in Total Upkeep – Tools – Logs you’ll actually find an error reading them, as well as the fatal error writing them in the restoration log. This was just a warning, so it didn’t prevent the backup from being taken.

I think it’s probably a good idea for the plugin to recognize these and skip restoring them without failing. I went ahead and added a feature request for our developers to add in the future.

3- Is there any way to specify these files to exclude on the restore instead of the backup?

No, there isn’t right now. I added that to the feature request as well, I think it’s a smart idea. That being said, I wouldn’t expect that file list to change in the near future, since WPCORE covers all of the existing WordPress directories. That’d take a major refactoring of WordPress’ core structure and the project tends to avoid drastic changes like that.

Hi Jesse –

I was previously using Updraft Plus, which worked very well for me, but recently GoDaddy decided to ban it from all their Managed WordPress sites. So you may have additional people looking for an alternative. I did a fair bit of research and your product looks like a great alternative to Updraft Plus for the functionality that’s important to me.

Thanks for all the answers to my questions, and this sounds reassuring.

I would like to encourage you to proceed with #3 — making Restore more resilient. You really don’t want a restore to completely fail. If your site gets completely lost, a 98% restore is certainly better than nothing at all. The user could then hopefully fix up the few issues and get back up and running. In my test, if the restore leaves the old files the site would probably still work perfectly well. So if these were treated as Warnings, instead of Fatal Errors, I think most people would be better off.

Like I said, no one wants to find out their backup is invalid when they absolutely need to restore it!

But with the Exclude feature you pointed out it seems to work well and I will start using it.

Thanks!

Mike