SiteGround’s Backup and Restore System is Weird

SiteGround’s backup and restore system works differently from every other service I’ve used before. In my opinion, it’s bad. Read to learn more.


UPDATE: SiteGround’s suggested workaround for restoring a backup to its exact state is to delete the installation from the Site Tools (and NOT from the Websites section) and then restore the backup.

For restoring a SiteGround backup to its exact state (without newly added files and database tables) first remove the WordPress installation from the Site Tools

A couple of days ago I wanted to test a new plugin on a client’s WordPress site, hosted on SiteGround. I know that some, if not most, WordPress plugins don’t implement their deletion process as they should, and hence leave traces even after you delete them. These traces can eventually lead to issues. So, I wanted to be able to revert the site to its exact state before the installation, in case I decided not to keep using the new plugin. I could have recreated a staging site (as the current one was corrupted), but I got lazy. So instead I created a manual backup.

After installing the plugin, I discovered it isn’t a good fit, so I went and restored my pre-installation backup. After a few seconds, I was notified that the restoration was successful. So far so good. But when I went back to the site a surprise was waiting for me: the plugin was still there, and still active.

why

I immediately contacted SiteGround’s support, which replied:

I see, allow me to explain please how the backup tool is configured to work: when you restore a website, the backup tool will restore the files that were on the server at the time of the backup creation, however newly added files will not be removed.

SiteGround’s Customer Care Representative

Actually, this response isn’t accurate. As I revealed after talking with more people at SiteGround, not just new files won’t be deleted when restoring, new database tables won’t be deleted as well.

SiteGround’s backups restore will leave new files and database tables, created after the backup, untouched.

Why SiteGround’s way of restoring a backup is problematic

There are a few issues here:

This behavior is essentially different from every other backup service. At least every one I’ve used before. Hence, this is very confusing and unpredictable.

It renders the backups and restores useless in many cases. A very common use of backups is to completely getting rid of a new, misbehaving, plugin. Actually, this exact use-case was mentioned in SiteGround’s Backups page in the past, as their current Website Backup Tool documentation reveals:

A screenshot of a screensot in SiteGround’s Website Backup Tool documentation

It might be too small, so I will repeat it:

Make controlled changes by creating backups before installing new themes or plugins […]

An old version of SiteGround’s information on their Backups page, as captured in a current documentation page.

You simply can’t do this with the way SiteGround’s backup and restore currently behaves.

Backups are, first of all, a security tool. SiteGround themselves write in their Backups page info: “Backing up your data is essential for the security”. Moreover, their backup tool is under the “Security” section of their Site Tools.

Now, why is this saying true? Because, for example, if your site was hacked and injected with a malicious file you can, with a click of a button, restore the site to its clean state, without the malicious file. With SiteGround’s backup and restore you simply can’t do this, as the malicious file is a new file, and hence will be left untouched. Sure, as SiteGround will explain, you can access the file system directly to fix such things. But it is much more complicated and takes much more time. The whole point of having a good backup service is to simplify such tasks. SiteGround’s backup and restore tool, in its current state, isn’t a security tool. It is merely an oops-I-deleted-something tool.

This unique restore behavior is not notified or documented anywhere.

SiteGround’s notification for confirming a restore – no mention of its unique behavior

SiteGround is using the word replace in its notification for confirming a restore. The obvious action to infer from such wording is: the current site state is being replaced with a previous, backed-up, site state. The part about the databases is even more conclusive – it says that the databases will be replaced. A database is made out of tables, so if you replace a database you actually replace all its tables. But, as SiteGround’s representative explained, this is not the case – new tables will remain untouched.

So, there is really no way of inferring SiteGround’s unique restore behavior from its restore confirming notification. Moreover, SiteGround’s Website Backup Tool documentation doesn’t mention this unique behavior as well.

This can actually be a great optional feature, in some cases

This kind of selective restoration can be helpful, but only in some specific cases. If SiteGround made such a feature optional, and better explained and documented it, it could have been great.

Conclusion

SiteGround’s backup and restore system works differently than every other similar service – it will keep new files and database tables, created after the backup was made, untouched. Moreover, it will do it without letting you know. In my opinion, in most cases, this is bad.


As a side note, I must say that I was a bit disappointed with SiteGround support. They did manage to explain to me eventually how things work (or almost, as I still have some gaps). But they did not respond to any of my comments about why are things like they are in the first place, and why it isn’t notified or documented.


Leave a comment

Your email address will not be published. Required fields are marked *