Today, a typical backup solution for WordPress sites looks something like this: once a day, probably during the night, some script creates a MySQL dump, optionally adds server files to the mix and creates a ZIP that is stored somewhere (locally or in the cloud). This is often managed by some plugin which makes things easier and there are also many advanced (paid) services that help with that. However, there are still a couple of inherent problems most of the current solutions have:
- Backups are not very granular. Even if you do backups every night, which is relatively good, you might lose some content if you restore e.g. the night’s backup in the following evening – all the morning’s content will be gone. Longer backup periods obviously make this much worse.
- MySQL dumps are space inefficient. Every time you do them, they export all the information from the database. Chances are that 99% of that information is already in some previous backup so you’re basically wasting a lot of disk space. Of course, cloud companies where you store your backup files very much like that :)
VersionPress was not created as a backup solution per se, however, it turns out that it is excellent for it. Just see for yourself:
With VersionPress, you have infinitely granular backups – the backup is continuous rather than point in time. You can return to any previous version of the site, to any time of day you like. Actually, VersionPress is not driven by time, it is driven by actions. So if there were no updates to a site e.g. for a week, VersionPress will not add a single byte to the disk space. And if the site goes crazy and there are new comments, posts, plugins updates, theme customizations etc. all the time, VersionPress adds a new “backup” (version) every time something like that happens.
Second, the internal storage of VersionPress is extremely space efficient. How much you ask? We tried to run VersionPress and one of the most popular WP backup plugins on a test site that is mostly focused on content (think slightly advanced multi-user blog). We let it run for 30 days while doing all the common things on that site like adding new posts, updating plugins, playing with themes etc. so VersionPress would grow its internal repository (otherwise, it would not be a fair comparison). The comparison plugin was set to create a backup every night. After 30 days, the results were:
• The classical solution required about 600 MB of disk space (30 days times approximately 20 MB)
• VersionPress required about 25 MB before compression, and keep in mind that because of the much better granularity, VersionPress actually stored more useful information in those 25 MB than the standard solution did in 600 MB.
Please note that this is just a quick example and you could certainly do something about the size of a classical backup – store fewer backups, maybe adjust the period, be more selective about what you put in there etc. But the point is, with VersionPress you don’t need to worry about any of that. You’ll get the whole site history in so few megabytes it’s almost ridiculous.
VersionPress is simply great as a backup solution.