Snapshot Backup Plugin for WordPress

I’ve just finished writing a new WordPress Plugin which creates a Snapshot Backup of your entire website: that’s your Database, current WP Core, all your Themes, Plugins and Uploads. The resulting single archive file is then uploaded to an FTP repository of your choice.

Peace of mind included 😉

Download from the official WordPress Repository

UPDATE AUGUST 2012

Due to heavy workload and high demand I can currently no longer find the time to support Snapshot Backup. I may pick up this project again in the future and put new PHP skills to work. Thank you for being kind enough to understand.

In the meantime I’ve discovered a wonderful by Daniel Hüsken which does all I ever wanted Snapshot Backup to do and more: It’s called BackWPup – download it here. It’s way ahead of my plugin and under active development.

———————————-

Disclaimer

I’ve recently been flamed a lot by users who are less than happy with this plugin. That’s tough, so I wanted to state some very obvious facts that most of us do take for granted:

This plugin does not work for everyone. It works fine for me, and I’ve written it for me and my own servers. I’m distributing it in the hope that it will be useful to others, but with absolutely no guarantee that it will work on every Linux system out there.

You are free to use Snapshot Backup, but I strongly advise you to test it on a dummy system before deploying it to your precious live site. Users have reported every possible horror scenario, from complete site deletion to an empty database file. Please test the plugin on your system and check that it creates a reliable backup that can be restored before relying on it to work. Remember: you are using Snapshot Backup at your own risk.

Thank you!

Installation

Upload the ZIP file under Plugins – Add New – Upload. Alternatively, unzip all files and upload via FTP client manually.

Activate the plugin and find the option Snapshot Backup in your Dashboard options.

Usage

Snapshot Backup has been designed with ease of use and simplicity in mind.

Once the plugin is activated, you’ll find a new top Level Menu called Snapshot Backup on the left. Under Settings you configure your FTP Details and and additional directory you’d like to back up. Now you can either head over to to Snapshot Backup and create a Snapshot manually, or you can setup automation and let the plugin create a Snapshot for you at regular intervals.

Make sure your wp-content/uploads directory is writable – Snapshot Backup needs somewhere to write files to locally before they get sent away to your FTP server (this would ideally be a second server, preferably with a different host in a different data centre).

In the current release your screen will go blank while the script runs through the various stages. Depending on the size of your site this could take a while… be not alarmed and keep an eye out for the browser status bar. While it appears your browser is working Snapshot Backup is working too. I’m attempting to fix this in future releases and give you a status report of each stage.

Automation

Included since Version 2.0 we have the long awaited automation feature. This creates Snapshots while you sleep and even auto deletes older ones. You can set all this up under Automation and receive a friendly email ever time a Snapshot has been created (optional).

For the automation to work I’m using the WP Cron feature, which in turn relies on your website being visited every once in a while. On live production sites with 100+ visitors per day you’ll be fine, but on low traffic sites you may notice that Snapshots are created at irregular intervals – I’m thinking of test sites with blocked search engines or brand new sites.

To help this along and make the process more accurate you can create a Cron Job which calls the index.php file in your WordPress installation directory (usually http://www.yourdomain.com/index.php)

Screenshots

Snapshot Backup Admin Menu
Success Screen at the end of the Backup
FTP Details Dialogue. Don't panic, your password won't show up -it's an old screenshot you know.

Snapshot Philosophy

Archiving dynamic websites isn’t all that easy and we all tend to forget that because the web is such a fluid thing. The idea of Snapshot Backup is that you may want to create an “as is” version of your entire website for archive purposes. With each click you’ll create a “time capsule” of sorts – this could be for legal, sentimental or security reasons.

Other solutions mirror or sync your installation – which is a great idea too, however if you only notice a week down the line that your site has been compromised then your synced copy most certainly is too. Snapshot makes it easy to go back to a clean version from x days/weeks/months ago.

How does it work?

Snapshot Backup first reads out your entire database into an file. Afterwards it uses the Linux shell command tar to archive all your content. Then it deletes the SQL file and then it uploads the resulting archive file over to your FTP repository.

Please note that this plugin does not work on Windows servers… sorry ;-(

Restoring a Snapshot

I’m working on a simple script that will do this for you. In the meantime you’ll be on your own – with some written guidance from yours truly. Have a look at this article which explains how to restore via FTP.

Known Issues

Even though this plugin is a great idea, it may not work for everyone. I’ve had reports from users reporting that either the plugin creates a 0MB backup file or does not include the database in the tar ball. The following hosts are known to be problematic:

  • Media Temple
  • Netpower
  • MyWebHost
  • Momwebs
On the other hand, on most hosts this plugin works just fine. If you are in the unlucky situation that you have a problem, please leave a comment and state your web host so I can add to this list.

Alternatives to Snapshot Backup

There are alternatives to creating a full backup of your site such as these (which will cost money):
Or you can try the excellent WP DB Backup Plugin which will read out your database. Following that you can simply login to your site via FTP and copy all your files to your local machine. Not pretty, not automatic, not fast, not convenient… but it’s free and it works 😉

Roadmap: The Future of Snapshot Backup

There are plenty of things I want to add to and improve on this plugin:

  • make sure the screen doesn’t go blank while the Snapshot is being created
  • add translation
  • add the ability to run Snapshot automatically via WP Cron or Cron Jobs done since 2.0
  • make the admin interface look prettier (and easier to find) done since 2.0
  • manage FTP repository from admin interface (i.e. list and delete older backups, local and FTP)
  • give this plugin its own website for documentation (snapshotbackup.org)
  • finalize Snapshot Restore script
  • add FTP Port selection done since 2.1
  • add cloud storage support (Amazon, Dropbox, etc)

If you have any suggestions for future features please leave a comment.

Enjoy Snapshot Backup responsibly 😉

About Jay Versluis

Jay is a medical miracle known as a Super Survivor. He runs two YouTube channels, five websites and several podcast feeds. To see what else he's up to, and to support him on his mission to make the world a better place, check out his Patreon Campaign.

215 thoughts on “Snapshot Backup Plugin for WordPress

  1. I was one of those that got the short straw. I used the plugin on my site, and when I updated (I use Amazon EC2 for hosting), it crashed the site, and has been down for over a week. It has Amazon stumped, and is getting increasingly expensive to try to fix.

    I think it’s a fabulous idea, and I should have used a more local backup solution. My question is, can a half hour session help me get the site back up again? The crash was pretty devastating, and I’d like to get our ministry up and running for our users asap.

    Thanks for your time, I really hope you’d be willing to help us out…

    Jordan

    1. Hi Jordan,

      In principle yes, I’m very happy to help you and your ministry out. It depends on a number of factors as to why your site went down so investigating those will be a challenge for the future – but if you have a snapshot then I can try and bring your site back the way it was.

      It’ll take me closer to an hour to do though depending on your host – if you’d like to go ahead please follow this link: https://wpguru.co.uk/support/restore-a-snapshot-for-me/

      After checkout you’ll be prompted for several credentials which I’ll need, in addition I’ll also require access to your host’s control panel for phpMyAdmin. And best of all, if I can’t fix it then you’ll get a full refund 😉

  2. Hi

    Besides the problems I previously mentioned version 2.1 runs smoothly. Got a small request though. Could you include an option to not upload to FTP? I would be very happy just to have Snapshot Backup create the tar and then stop.

    I manage several websites for family and friends, and have Snapshot Backup create a tar for each one. Once in a while a run a script that goes online and retrieve all the backups at once. This words beautifully. Unfortunately I have to allow Snapshot Backup to upload to a FTP-server or else it wont create the backup.

    R.

    1. Hi Ronni,

      glad to hear 2.1 is running smoothly! As for your request, it’s already implemented: just leave all FTP details blank and Snapshot will only create a local backup. You can still give it a prefix though. I’ve just tested it manually and with automation and both options work fine.

  3. Hey Jay,

    The plugin saved my butt recently. Thank you!

    I reintalled WP and the plugin, and now I’m getting an empty database snapshot error. The backup says it’s 0 MB. Any ideas?

    Best,
    Jordan

    1. Hi Jordan,

      glad to hear it helped you out, and great to see your website is back up and running.

      I’ve come across the empty database problem before, and I have no idea why it doesn’t work on some server setups. I’m getting it myself on MAMP, but works fine on CentOS. Who are you hosting with? What’s your hosting configuration?

      It’s probably worth checking if the file is actually empty, or if it’s just the error message that comes up.

      1. Very strange… woke up this morning and it worked fine… 197MB file, in about 15 seconds.

        I’m on Amazon Linux running Apache. I don’t know much about the configuration…

        But that showed me a little QA mention: On “Archiving your Website” it is spelled “Archving” on the snapshot. just something for your next release…

        1. Thanks for letting me know – I’ll test it out on Amazon. Is it part of their AWS services? I’ve never tried to create an Apache instance with MySQL on AWS – sounds exciting. Glad to hear it’s working again though.

          How embarrassing about the typo – I’ve never noticed this before, my wife kindly pointed is out to me only a few days ago 😉

        2. I’ve heard it’s one of the most unnecessarily tedious setups for WP you can do, BUT it’s crazy cheap hosting, AND free for the first year. It’s great having EC2 and S3 right next to each other, it’s really affordable… but difficult.

          Hey, while I have you, I’m really in a pickle… when we reinstalled the backup (theme forum isn’t very helpful) the theme individual posts on my site are broken… Here’s a link to the broken page: http://www.cheapochurch.com/?p=332.

          You’ll see the code just breaks off, but the single.php file is just fine, and everything on the back end seems to be working… Does anything jump out at you right off the bat?

        3. I see, are you expecting something like http://www.cheapochurch.com/category/posturl/? In which case it looks like the Pretty Permalinks need to be reset. This happens when the .htaccess file in the root directory hasn’t copied across. Have a look if it’s there, and if not head over to Settings – Permalinks, don’t change anything and just hit save. That will create a new one if it can write to the directory.

          Were you using a cache plugin? This may also have inserted rewrite rules here.

        4. Jay,

          Yes, I use Quick Cache. Actually, ANY permalink structure beyond the default results in a 404 error, super bizarre. I’ve reinstalled a fresh theme twice (Continuum from Outerspice web), they can’t figure it out either.

          This is weirdest problem I’ve seen on WP. I’ve tried disabling plugins, and the problem still persists…

        5. In that case, I’d try to delete the .htaccess completely, disable the cache plugin and reset permalinks to defaults, see if that works. I saw the full post content earlier when the TwentyEleven theme was active, so it looks like WordPress is still working fine. Try with TwentyEleven again and see if that brings your posts back to life.

        6. While deleting the cache plugin, I discovered something that might be helpful. We got this error message:
          Plugin could not be deleted due to an error: Unable to locate WordPress Plugin directory.

          Then, we realized, when we restored the Snapshot, that originally it lived in this folder on our WP install:
          www/public_html…
          But on our new install, it was configured to now live in:
          var/www/html…

          Does that open up possibilities? Being able to delete the plugin and the .htaccess would be next.

          Apparently the site isn’t connecting correctly with FTP. You’re right, all the posts work perfectly with any other theme, but I realize now that it isn’t connecting properly. Is there a way to reroute where it finds the plugins folder?

        7. Ah, you need to let the database know this. Have a look in the wp_options table, there are two values you need to change. HOME and SITEURL, one is the URL and one is the full server path. That should tell WordPress to point to your new location.

          If the site works fine with the default theme, then I don’t think it’s the cache plugin.

        8. Hi Jay!

          I’m back… Ok, I’ve switched servers. I think this is one you’d DEFINITELY know the answer to. I’ve got the snapshot backup and .sql file. When we ran the script, we ended up back on the broken site (which means the files are weird, not the snapshot). Before the site crash, I couldn’t get a WP .xml file exported (sucks for sure).

          Inside the snapshot, it’s gotta have all my posts/pages/users. How can I get that information without running the script? I know the info is in there… is there a way to get all the content out, instead of rewriting everything?

          I VERY much appreciate you talking me through all this. I’ve recommend the snapshot to many!

          Jordan

        9. No problem Jordan, I’m sure we can figure this one out. There are several steps involved, let me outline them for you.

          First, you need access to phpMyAdmin and import the .sql file into an empty database. That will bring your content back online.

          Next copy the contents of the unTAR’d snapshot onto the new server – i.e. all remaining files.

          Final step: tweak your wp-config.php file to point at that new database you’ve populated, with user name and password.

          If you’ve done all those steps correctly, your site should be back up to the same point as when the snapshot was taken.

          Good luck 😉

  4. For me it’s still not deleting the oldest snapshot on the FTP server. In FTP server’s logs i can see that after the newest snapshot is transferred, it’s deleted after a few moments (in the same connection).

    I’ll try another FTP server.

    1. Hi Bogdan,

      I’ve traced this down to the way the directory is being read out. I’m using the ftp_nlist() function which presents the directory in temporal order, i.e. youngest one first, oldest one last. But somehow it mixes things up every now and again…

      The List Snapshots option will show you exactly how the auto-delete function sees the content: the snapshots at the bottom of that list will be deleted, the ones at the top will stay.

      I’ve noticed that when I mix snapshots form different sites with different prefixes, these can get mixed up in terms of timely order – so I found that an younger snapshot is further down the list than an older one. Doesn’t make sense to me either…

      As a way out of this I’ve added a check with which you can disable the auto deletion altogether: add anything higher than 99 under Automation – Auto Delete and everything is kept for you. I future versions I’d like to include an interface here which allows you to mark and delete snapshots manually from here.

  5. I want to limit the number of snapshots so the the auto delete function is needed.
    In the listed snapshots i see the oldest 3 snapshots, 3 is my limit.
    On the server i can see indeed the latest snapshot.
    I don’t have mixed snapshots , from different dates. I always deleted all the snapshots when i started testing.

    1. You know, I’ve just had a look at my code again and had an idea on how to avoid this.

      Currently (v2.1) the auto delete function is called before the new snapshot is written to the FTP repo. That’s wrong – I should delete the oldest one first, then write the latest one. Not only is this easier on space usage, it also means that your latest snapshot shouldn’t be deleted any more.

      I’m currently working on adding Amazon S3 but since this is a quick fix I may put out and update today.

  6. I’ve just added a quick fix to a Maintenance Release, Version 2.1.1:
    This switches the way auto delete operates by deleting the old snapshot(s) first, and then writing the new one to the FTP site.

    I’ve also corrected the Archving spelling mistake which has been there since Version 1.0 (ouch).

    Sadly this update does not address the empty database problem which occurs on some setups, pretty much because I don’t know how to fix it. Yet. It’s next on my list, together with adding Amazon S3 storage.

  7. Hi again Jay,

    haha, I should elucidate… we tried that, with Bluehost’s technical support on the line. Ran the script, backed up the files, and saw no change in the site even after fixing the wp-config file. The guy was stumped. I’m telling you, this site is cursed. I just found out a way to look at cached versions of the site through google, so at least the big amount of content can be moderately saved.

    When we ran the script and replaced the files, the site eventually went back into a 404 error, so it was back to scratch. If this is just one of those things that CAN’T be fixed, I suppose I can try the hard way. You’re the backup expert, so if you say it’s a done deal, I believe you.

    Jordan

    1. It’s got to be the cache then – that’s why you’re not seeing any changes to the site. I remember doing a job for a client thinking I’ve gone mad when my changes just didn’t appear. I was questioning every CSS command I was doing until I found out that some aspects of the blog being cached while others weren’t.

      Switching the cache plugin off – especially after a site crash or misconfiguration – can have that effect. Sounds to me like you’ve taken all the right steps and that cache is messing with you. I’d say switch that plugin off, delete it even, see if there’s residue in .htaccess and then remove the line that enables cache in your wp-config.phop too.

      The other oddity about your site is the theme though. The fact that content seems to show up fine with the TwentyEleven theme means WordPress is working fine – wonder if your theme has cache options too. See if there’s a cache directory in it somewhere, clear it and try again. If all else fails, I’d try a different theme.

    1. Hi Jack,

      once you’ve completed the restore your wp-config.php file will be exactly like it was when you created the snapshot – however your new database may have different credentials. You need to tweak the database host, user name and password accordingly.

      I haven’t written instructions for SSH restore yet – but that’s a great idea, I’ll do this over the weekend.

      1. thanks for that, I can edit the wp-config.php file , no? but what lines , the password looks the same but the log in does not like my user name after I get this restore up and running, I will upgrade by host to the SSH.

        1. I am looking at the wp-config file, one from a back up I have here and one from the restore I uploaded via your restore instructions, and they are the same ? so I am missing something on the “tweak”.
          I imported the SQL data after the upload and overwrite , and after the SQL data was edited per you instructions to “drop “all WP tables. the first import via phpmyadmin did not work via firefox. it did work however via google crome. the wp tables are back now. coming in the back door via wordpress sees the blog ( stats) but will not allow me to access the dashboard. ?

Comments are closed.