Database Versioning with WP Migrate DB Pro

One of the hidden gems in WP Migrate DB Pro is the ability to backup your WordPress database just before it’s due to be replaced during a migration.

Let’s pretend you’re working for a client developing their website. You currently have 2 copies of this website, a staging version on a public server and a development version on a local server. You’ve instructed the client to update the staging server with his/her content.

Once in a while you’ll want to pull down this new content from the staging server into your development environment. With the backup option checked, your local database will be backed up before pulling from staging. This is handy for a number of reasons.

Imagine if your client was poking around in the WordPress admin panel and accidentally changed a setting or two by mistake. If you pulled those changes from staging, your development environment would also bare those accidental changes. With the backup option selected it would be as easy as importing that backup SQL dump (via command-line or phpMyAdmin) to revert those changes.

To enable backups simply select either ‘push’ or ‘pull’, expand the ‘Advanced Options’ and check off ‘Backup the database that will be overwritten’.

By default backups will be stored in the ‘wp-content/uploads/wp-migrate-db/’ directory, though this may change depending on your directory structure.

About the Author

Chris Aprea

Chris wrote a ton of code and helped lots of customers for Delicious Brains during his 2-year stint with us. He has since moved on to other things.

  • Ross McKay

    NB: there’s a small security risk associated with this if to do it on a publicly accessible server (e.g. a staging server, pulling from the live site), because the backup file could be accessible to someone snooping for such files. Granted, they’d have to know that the website has WP Migrate DB Pro (easily determined), and be able to “guess” the backup file name (db name + “-backup-” + datestamp + “.sql”), but it’s possible.

    But for dev machines, it’s a very nice feature 🙂

    • The next release of the plugin also adds a 5 character salt to the end of the SQL dump filename, even extra added security.

      • cmb

        It’s much worse than that, and surprised my report a few weeks ago (which you replied to) hasn’t been taken more seriously, so making it public. Due to lack of an index.html in the uploads folder, all the files are visible to a simple guess of where the standard uploads folder is (i.e. /wp-contents/uploads) – salting the filenames will make no difference. In my case, I’ve got Gravity Forms with user submitted confidential information being stored in the backup dump! Not nice.

        • I can assure you that we are taking all security-related feedback seriously. If a developer chooses to check off the backup option, it is currently their prerogative to ensure those backups are safely stored. The backup option explicitly states that files will be stored in their uploads folder. That being said, we can certainly make the default behaviour more secure and less work for the developer. And that’s exactly what we’ve already coded for the next release.

          The next release of the plugin stores SQL dumps within a subfolder (default: /wp-content/uploads/wp-migrate-db/) and adds an index.php “silence is golden” file to that folder. This is already coded and being tested by some of our customers who’ve been given a pre-release to test in their unique environment where 1.1.3 was having issues.

          Furthermore, there is a filter on the path of the folder where backups are stored, so developers can actually change where the files are saved, ideally an offline folder.

          • cmb

            Thanks Brad. Sorry I was feeling grumpy ;-(

            Offline is perfect, hope it works with e.g. ../../private which would be off the web-accessible filepath.

  • tnorthcutt

    This is a good workaround/protection for accidental overwrites.

    FWIW, the holy grail enhancement you guys could make to WPMDBP would be a way to enable *merging* a pulled database dump with your local environment (or vice versa). This would allow for a situation where e.g. Joe is making changes on his local site, while at the same time, Sally is making (unrelated) changes on a “live” site, and Joe is then able to pull down those changes without having to manually re-enter the new content on his local site, while preserving his changes.

    I realize that’s no easy task (and may be impossible?), but I figured I’d put it out there.

    • Yep, we have some ideas of how this might be possible and plan to work on it soon.

      • tnorthcutt

        Awesome. If you need beta testers, I’d be happy to help. That would be a huge improvement to our workflow.

  • Brent Jett

    Love the auto backup and the plugin in general. We use it on all our (~50+) sites. Makes life so much easier. One thing I’d love to see is a comparison view between two sites, pointing out the differences between two instances (local vs. stage, stage vs. live). Even a single-post “push” live feature when moving the whole database isn’t necessary. Totally understand the complexities and love that you guys are working on really usable tools! Also enjoying the Apply Filters podcast.

  • rk


    I am new to this plugin and i have 2 environments dev and prod. each have s3 buckets where the static files are being served from. When i pull prod db changes to dev the s3 urls of dev files are being changed to prod bucket. is there any workaround for this? am i missing anything here