It’s time to call for backup! But who do you call?! Introducing Snapshot, the smart, automated, ready on-demand time-traveler from WPMU DEV. He’ll snap and store backups of your WordPress and Multisite for one-click restoration. Snapshot’s got your back...every time.

Version 3.1.4

Fix: Re-added change destination directory feature.

Fix: Minor UI error on dashbord and snapshot progress bar.

Fix: Minor error on PHP 5.4.

Changelog

Version 3.1.4

Fix: Re-added change destination directory feature.

Fix: Minor UI error on dashbord and snapshot progress bar.

Fix: Minor error on PHP 5.4.

Version 3.1.3

New: Snapshot now uses V2 of Dropbox API.

New: Dropbox authentication uses OAuth 2 instead of OAuth 1, fallback system has been created for old destinations.

Corrected issues with the restore looping logic user for large tables.

Version 2.4.2.4

Changes to Google Drive destination logic. Moved loading of external Google SDK into destination init() function of destination class. See if this gets us past the reported library conflicts.

Version 2.4.2.3

Modified priority for 'cron_schedules' filter registration used within Snapshot to register custom backup intervals for WP_Cron. This is to help circumvent issues when other plugins tend to ignore the proper use of filters.

Added optional define 'WPMUDEV_SNAPSHOT_DESTINATIONS_EXCLUDE' which can be added to the wp-config.php to prevent certain destinations from being loaded. Possible values are SnapshotDestinationDropbox, SnapshotDestinationGoogleDrive, SnapshotDestinationAWS, SnapshotDestinationFTP, SnapshotDestinationGreenQloud. Multiple destinations can be included as a comma separated value.

Version 2.4.2

Added support for Google Drive as a destination.

Added support for generic AWS/S3 type system like DreamObjects

Corrected stray comma on restore SQL.

Version 2.4.1

Corrected reported issue where the site lookup was not functioning properly on the restore panel when using site ID under.

Correctes reported issue where if the archive was in a sub-directory on the local server the restore init failed.

Updated import panel to allow import or archives local server from alternate locations.

Added support logic when using non-default destination directories. If move of the temp archive to final destination fails then the archive is moved to default snapshot archives folder instead of simply aborting.

Version 2.4.0.9

Corrected issue with WPEngine and Dropbox include paths for OAuth.

Corrected to restore logic where non-WordPress tables are included.

Reworked restore logic for global tables (users & usermeta) to be setup in segments like other tables.

Update to migration logic. Added support logic to correct old style (pre-MU 3.5) image URLs stores in posts when restoring to new post MU 3.5 site. In pre-MU 3.5 the image URLs were formatted such http://www.site.com/files/2013/12/image.jpg while in 3.5 and new installs the image URLs are http://www.site.com/wp-content/uploads//2013/12/image.jpg. Prior versions of Snapshot only update the domain part of the URL. Reminder Migration logic is still considered beta.

Testing for WordPress 3.8

Update to WPMU DEV Dashboard Notifications library.

Version 2.4.0.6

Fixed reported issue on files restore. When selecting the 'Restore all files' option in some cases none or not all files were being restored.

Version 2.4.0.5

Fixed reported issue where blog lookup by ID was no longer functioning under Multi-domain configurations.

Version 2.4.0.4

Corrected reported issue of snapshot handing when ONLY Files to be included in archive and there are no files to add to the archive. The result is an empty archive containing only the manifest file.

Under Multisite added support logic for Domain Mapper when selecting which sub-site to backup. Users can now enter full mapped domain instead of just the local sub-domain.

Corrected reported issue where files were not being included in manual archives when selecting 'common files'.

Version 2.0.4.2

Changed logic for handling files when building zip archives to cut down on zip archive overhead.

Removed legacy support for hp sessions. Now using own containers to hold temporary variables.

Updated instructions on Import page to help with any confusion between an import and restore

Fixed some typos on labels.

Version 2.4.0.1

Corrected reported issue causing 'run now' option to not be available on regular WordPress sites.

Corrected some PHP Notices and Warnings

Version 2.4

Added migration logic. This is still considered beta. Migration types supported are Regular to Multisite, Multisite to Multisite (same system or different), Multisite to regular. Using the migration logic you can even change the site URL. Note the destination blog must already be setup and working within WordPress.

Added backup logic to include users and usermeta data related to the blog being archived. Only user who's primary blog is the archive blog.

Rewrite of the import logic. You can now pull in external files from public URL instead of needing to upload the archive to your server first.

Code cleanup on some of the archive logic.

Version 2.3.3.6

Corrected logic to Zip Compression setting on archive restore.

Version 2.3.3.5

Removed debug output.

Version 2.3.3.4

Fixed issue with reported phantom table queries when backup for main site within Multisite.

Added support for scheduling backups when WP_CRON is disabled.

Added output on System Info for OpenSSL installed and version.

Added output on System Info for cURL installed, version and protocols supported.

Version 2.3.3.3

Fixed issue with blob lookup when using Multisite subdirectories

Version 2.3.3.2

Correction to FTP destination logic to include ftp_ssl_connect function which allows support for FTP with TSL/SSL

Fixed issue where users were using backslashes in in destination paths.

Fixed page icon not displaying correctly on archives settings page.

Version 2.3.2.1

Fixed bug on archive purge when set to 1.

Version 2.3.2

Corrected issue with Dropbox reporting Bad OAuth Request

Added some support logic to prevent abort on hosts where php_uname is disabled. The php_uname function is used for AWS Destinations library.

Version 2.3.1

Corrected issue with FTP Destination not setting timeout correctly.

Adjusted display for Interval to not show percent transfer for all destinations.

Cleanup some logic for setting/removing scheduled WP_CRON tasks on plugin deactivation and activation.

Version 2.3

Added blog lookup option on Add New Snapshot form. This replaces the previous blog dropdown used to select the backup target. Should work better for very large systems.

Fixed but where phantom snapshot directories were being created under sub-site uploads directory tree.

Fixed issue where Snapshot configurations are only initialized on the Network or primary site admin area.

Version 2.2

Added logic to support folder and file sync to Dropbox destination.

Added logic to backup file sub-sections instead of attempting complete section. So instead of trying to submit the entire plugins folder. We are adding each plugin sub-directory, each theme sub-directory, each media year.

Added role capabilities manage_snapshots_items, manage_snapshots_destinations, manage_snapshots_settings to allow fine tune of who can access Snapshot. This is Single WordPress sonly. On Multisite this is still only Network Admins. http://premium.wpmudev.org/forums/topic/snapshot-features-requests#post-309939

Added more PHP information to 'Server Info' Settings panel. This should help support and users get at information like the PHP timeout values, etc.

Improved logging logic for new snapshots. Entry and logs now created at start of snapshot instead of on completion. This should allow for better debugging if the table backup aborts.

Version 1.0.2

Rewrite of core backup/restore logic. Should help Improve stability for users.

Added Scheduling for automated snapshot creation.

Dropped the Activity log. Each Snapshot nw contains the set of all archives.

Logging for scheduling snapshots written to physical file. Should also help for debugging.

As part of the backup/restore data is handled in 'segments'. The Segment Size can be controlled by a user setting. The segment size is the number of rows to backup/restore per request. So a table containing 80,000 rows can be split into 10,000 row requests. Much easier than trying to do this in one request.

Version 1.0.1

Time display - When setting the WordPress timezone to UTC values the time displayed remains GMT. See comment http://premium.wpmudev.org/forums/topic/new-release-snapshot#post-181304

ables display - As Timothy point out http://premium.wpmudev.org/wp-content/uploads/2012/02/Screen-Shot-2012-02-11-at-11.05.13.png when adding a new snapshot on the primary site under Multisite the tables listed included all table. Not those just related to the viewed site.

Uninstall - I had started on the delete plugin uninstall hook but left it unfinished. Now properly removing snapshot files and options entry. On Multisite this delete only occurs on the primary site since the sub-sites do not really have the ability to delete a plugin. http://premium.wpmudev.org/forums/topic/install-error

When activated on a single site install of WordPress, go to Snapshots > Settings.

Configuring the Settings

We need to first configure the folder where we want these backups done. Click on Settings now.

You can customize the name of the folder here, and change it to anything you like. We’ll move the files already backed up over for you. How cool is that!!

We will then want to set how many records are backed up per request. This is titled Database Segment Size.

The Segment Size can be defined as the number of rows to backup per table per request. The Segment Size controls the backup processing when you create a new snapshot.

During the backup process, Snapshot will make a request to the server to backup each table. You can see this in the progress meters when you create a new snapshot.

In most situations this backup process will attempt to backup the table in one step. But on some server configurations the timeout is set very low or the table size is very large and prevents the backup process from finishing.

To control this, the Snapshot backup process will breakup the requests into smaller ‘chunks of work’ requested to the server.

For example, let’s say you have a table with 80,000 records. This would take more than the normal 3 minutes or less most servers allow for processing a single request. By setting the segment size to 1000, the Snapshot process will break up the table into 80 small parts. These 1000 records per request should complete within the allowed server timeout period.

The next section, Server Info, displays everything you need to know about the particular configuration of your install. This can be very useful information indeed if you ever need to contact support with any issues.

We can then set a new memory limit. Keep in mind if your database is growing in size, then you will need more PHP memory to process that. If there isn’t enough, then PHP will time out with memory errors.

The next settings area allows you to specify files or directories that will be excluded automatically from all snapshot configurations.

You can also setup exclusions specific to a single snapshot via the configuration screen (see Starting A Snapshot below). The exclude logic uses pattern matching. So instead of entering the complete server pathname for a file or directory you can use simply use the filename of parent directory.

For example to exclude the theme twentyten you could enter this one of many ways: twentyten, themes/twentyten /wp-content/themes/twentyten, /var/www/wp-content/themes/twentyten. Regular Expression are not allowed at this time.

The Error Reporting section controls how Snapshot will handle an error condition during the backup / restore processing.

There are two columns for each type of error. The ‘stop’ column controls if Snapshot will abort the current process should that type of error be reached. The ‘log’ column controls if the type of error and details will be written to the processing log. In most cases you want to set ‘stop’ for Errors only. And set ‘log’ for all.

The final section lets you select which zip compression library to use.

The zip library is used during the backup and restore processing by Snapshot.

In most cases ZipArchive is built into PHP and generally faster than PclZIP. ZipArchive uses files whereas PclZIP uses memory for temporary storage when compressing large files.

That’s it for the settings — all done.

*BETA* WPMU DEV Hosted Backups

As of the most recent release, Snapshot can now integrate with our new backup service, which will allow you to store up to 10GB of backups in our cloud. It’s very important to note that this feature is still considered to be in beta, so expect a few bugs and quirks early on. Please report any issues you find in our support forums.

Using the hosted backup system is very simple. You’ll be up and running in a few clicks. You will need to have the WPMU DEV dashboard installed, and be an active subscriber in order to use the Snapshot hosted backup service.

Start by clicking the Full Backups item in Snapshot’s admin menu tab. This will bring you to the settings page. There are only three areas to be concerned with. In the left panel, you’ll see general information about your Snapshot schedule, and a list of all your current backup files, once you’ve created some backups.

In the right panel, you’ll see a box for creating a backup schedule, and one for settings.

In the settings box, you’ll need to enter your Snapshot secret key. There’s a link that will take you to the Hub on WPMU DEV, and you’ll be shown a pop up with your Snapshot key ready to copy. You can also access this by going to the My Websites tab in your Hub, then choosing the site you’d like to add Snapshot backups to, then selecting the Backups tab.

In the schedule box, choose between daily and weekly backups, and set a time when you’d like the backup process to start.

You can select the number of backups you’d like to store remotely in our cloud, and also choose to enable logging, a feature we’ve carried over from the other destinations in Snapshot.

Once you’ve successfully created your first Snapshot backup and it’s been successfully uploaded to our cloud, you may restore it at any time, from either the Snapshot archive on your site, or from the My Websites tab in the hub.

Easy as falling off a log.

Snapshot Destinations

Destinations are external locations where you can store your Snapshots so they’re secure and accessible even if your server crashes.

A destination is a remote system like Amazon S3, Dropbox, SFTP or GreenQloud. Simply select the destination type, then fill in the details. When you add or edit a Snapshot you will be able to assign it a destination.

When the snapshot backup runs, the archive file will also be sent to your selected destination.

To set up a destination, simply click the Add New button next to your preferred service, and follow the directions. Go ahead and set up a destination now for the next steps.

Note for Google Drive destinations: when setting up your destination at Google Drive, you may want to double-check under APIs & Auth > Consent Screen that Email Address & Product Name are filled in, otherwise you may get an error.

Note for Amazon S3 destinations: when setting up your destination at Amazon S3, you must set “Amazon S3 Full Access” permissions in the user policy of the user you are connecting with.

Starting A Snapshot

In the Snapshot menu, click on “Add New.”

Here we will want to give our Snapshot a name. It doesn’t really matter what you call it because it’s all relative to you. You can add some notes, as well as a reminder of what you’re performing with Snapshot.

In the next section, you can select which files to include or exclude from the Snapshot.

You can choose to not include any files, include only common files, or select specific files you want to include.

You can also list additional files to exclude from this snapshot. This is handy to exclude very large files like videos that are 2G in size that you may be hosting, but know you have a backup elsewhere.

Next we will want to decide what tables to take a Snapshot of. You have 3 basic options:

Do not include database tables in this Snapshot.

Include all blog database tables in this archive. This will automatically include new tables.

Include selected database tables in this Snapshot.

Selecting the 3rd option will expand the section so you can select exactly which tables you want to include. The first set of options are for the default WordPress core tables — the ones for users, usermeta, and so on.

The next set of options are for the extra tables added by themes and plugins. Any tables added by WordPress, themes, or plugins are all optional, and you can choose which ones you need!

Now we need to tell the plugin when to run & archive the backup.

When selecting the Backup Interval, please note that the Snapshot scheduling process uses the WordPress Cron (WPCron) system. It should be understood that WPCron is not precise. If you schedule a Snapshot for a specific minute of the hour, WPCron may not execute at exactly that time. WPCron relies on regular front-end traffic to your website to kickoff the processing.

You can also specify the total number of local archives to keep for this snapshot. Once the archive limit is reached, older locally stored archives will be removed.

In common cases you may want to set the backup interval to once a week. Then set the number of archives to keep to 52 which would give you a year or backups. But keep in mind on a large site this will be a lot of extra disk space required.

Finally, select where you want to store your backup.

In the Backup Destination dropdown, you can select to archive your backup locally, or choose any of the Destinations you have already set up. If you need another, simply click Add More Destinations.

You can also use the optional Directory to override or supplement the selected destination directory value.

Once you are happy with all your choices here, then all that’s left to do is to click on the “Create Snapshot” button. … So let’s do it!

You’ll then see a new screen that shows you the backup progress as it’s working.

If you need to abort the backup at any time and start over again later, simply click the Abort button that appears next to each segment as it is being backed up.

And don’t be alarmed if this takes a while or if the backup does not appear instantly. These things take time you know. ;-)

Go grab yourself a beverage whilst you wait if you wish. :-)

Once it’s done, the plugin will let you know with a friendly notice:

Where Are My Snapshots? Can I Restore Them?

You will notice in the Snapshot menu there is an option for “All Snapshots.” Click on that, and you will get a list of all the Snapshots you have already archived. It really is that easy!

As you’ll notice on the page, you can edit, run, restore or delete a backup.

You can even view which core & optional tables you backed up by clicking the corresponding link:

At the far right of each snapshot listed, you’ll find links to download the snapshot to your computer or view the archive for that particular snapshot. You can also view or download the log of all actions performed during the backup.

How awesome is all that!!

Importing a Snapshot

If you have Snapshots stored on a remote server, or have manually uploaded them to to your local folder, you must import them first so the plugin will recognize and show the archive in the All Snapshots listing.

Note that if you are importing from a remote server, the remote archive must by publicly accessible as this import process does not yet support authentication.

Once you have successfully imported your remote archive or scanned your local folder, you’ll see a success message with the import results.

If you have set up the archive to save to an alternate directory, then enter the full server path to the directory where the archive resides in the URL field.

You can now select your imported archive, or perform operations on it, from the All Snapshots page.

If you’re stuck, need some help, or have a suggestion, then get involved with the community through our forums!