DOCUMENTATION

Revolutionary Backups Documentation

Schedule full and database backups, ship them off-site to S3, Google Drive or Dropbox, verify their integrity, and restore your entire site in one click, all without leaving WordPress or touching the command line.

Getting started

Install and create a working nightly backup in five minutes.

Schedules & retention

Control what to back up, how often, and how many to keep.

Incremental backups

Fast, small runs that still restore a complete point in time.

Off-site destinations

Ship archives to S3, Backblaze B2, Google Drive, or Dropbox.

Restoring & migration

One-click, rollback-safe restore and host-to-host migration.

WP-CLI & hooks

Automate backups from the command line and extend with filters.

Introduction

Revolutionary Backups is a complete backup and restore solution for WordPress. It pairs a set-and-forget schedule with off-site storage and a genuine one-click restore. Each run produces a restore point, a verified, dated snapshot of your files, database, or both, that you can restore, download, or use to migrate to a new host.

The core idea is simple: a backup is only useful if you can get it back. So every archive is checksummed on upload, re-verified on a schedule, and restored through a staged, rollback-safe process rather than a risky in-place overwrite. You bring your own storage (S3, Google Drive, Dropbox, Backblaze B2), so there are no metered fees and you keep full control of your data.

This guide walks you from installation through automation. If you just want a working nightly backup in five minutes, jump straight to Your first backup.

Tip: The single most important setting is an off-site destination. A backup that lives only on the server it is protecting will vanish with that server. Connect S3 or Drive first, then build your schedule on top of it.

Installation

Revolutionary Backups installs like any standard WordPress plugin. You can install it from the bundled .zip archive or directly from the Revolutionary Plugins hub.

  1. Upload the plugin. In your WordPress admin, go to Plugins - Add New - Upload Plugin and choose revolutionary-backups.zip. Click Install Now.
  2. Activate. Once installed, click Activate. A new Backups menu appears in the admin sidebar.
  3. Run the setup wizard. On first activation the wizard checks that your server can write to the backup staging folder, confirms a working cron, and offers to create a default daily schedule. You can change all of this later under Backups - Settings.
  4. Verify your license. Paste your license key under Backups - Settings - License to unlock off-site destinations, incremental backups, one-click restore, and automatic updates.

Heads up: Backups run on WordPress cron, which only fires when your site receives traffic. For low-traffic sites, set up a real server cron that hits wp-cron.php on a fixed schedule, or use the WP-CLI command from a system crontab so backups never get skipped.

Your first backup

Let's connect a destination and create a working nightly backup. The whole process takes about five minutes.

  1. Connect a destination. Go to Backups - Destinations, choose Amazon S3, Google Drive, Dropbox or Backblaze B2, and follow the connect flow. For S3 you paste an access key, secret, region and bucket name; for Drive and Dropbox you authorize with one click.
  2. Create a schedule. Open Backups - Schedules - Add New. Choose Full site, set the frequency to Daily at 2:00 AM, point it at your connected destination, and keep the last 30 restore points.
  3. Run it once now. Click Run now on the dashboard to fire the first backup immediately. Watch the progress bar; the first full run takes the longest because nothing has been backed up yet.
  4. Confirm off-site upload. When the run finishes, open the new restore point and confirm it shows your destination and a Verified badge. That badge means the archive uploaded and its checksum matched.
  5. Set a failure alert. Under Backups - Settings - Alerts, add your email or a Slack webhook so you hear about any run that fails or any integrity check that trips.

That's the full loop: connect, schedule, run, verify, alert. Everything else in this guide refines these same five steps.

Schedules & retention

A schedule defines what to back up, how often, where it goes, and how many restore points to keep. You can run several schedules at once, for example a full-site backup nightly and a leaner database-only backup every few hours.

Setting What it controls Typical value
Scope Full site (files + database), database only, or a custom file selection. Full site nightly, database every 6 hours
Frequency How often the schedule fires, plus the time of day it prefers. Daily at 2:00 AM
Destination Which connected off-site target receives the archive. Amazon S3, us-east-1
Retention How many restore points to keep before the oldest is pruned. Keep last 30
Exclusions Folders or file patterns to skip, such as caches and large logs. Skip wp-content/cache

Retention is applied per schedule, so your nightly full backups and your six-hourly database backups age out on their own independent timelines. Pruning runs after a successful upload, never before, so you are never left with zero valid restore points while a new one is still being written.

Tip: Exclude caches, generated thumbnails you can regenerate, and verbose log folders. Trimming these from the file selection often cuts a full backup by half and shortens every run.

Incremental backups

After the first full backup, Revolutionary Backups switches to incremental mode. Each subsequent run scans for files that changed since the last snapshot and captures only those, alongside a fresh database export. The result is a chain of small, fast backups that still restore as a single complete point in time.

  • Faster runs: a nightly incremental on a typical site finishes in a minute or two instead of grinding through gigabytes.
  • Less storage: off-site usage grows slowly, since unchanged media is not re-uploaded every night.
  • Whole-point restore: when you restore, the plugin reassembles the base plus the right increments automatically. You always restore a complete site, never half a one.
  • Periodic full re-base: on a configurable interval (weekly by default) a new full backup is taken so the increment chain never grows too long.

Note: Incremental backups depend on the base full backup remaining intact. Keep your retention high enough that at least one full backup always survives in the chain. The plugin warns you if a retention setting would prune the only full base.

Off-site destinations

Destinations are the external storage targets your archives are uploaded to. Connect as many as you like and point different schedules at different destinations. Credentials are stored encrypted in your database and never leave your server except to talk to the storage provider.

  • Amazon S3 and any S3-compatible bucket (Wasabi, MinIO, DigitalOcean Spaces), authenticated with an access key and secret.
  • Backblaze B2, a budget-friendly object store using an application key.
  • Google Drive and Dropbox, connected with a one-click OAuth authorization.
  • SFTP / local path, for keeping a copy on a separate machine you control.

For S3, scope the access key to a single bucket with put, get, list and delete permissions, nothing more. The plugin only needs to write archives, read them back during a restore, list restore points, and prune old ones per your retention rule.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect":   "Allow",
    "Action":   [ "s3:PutObject", "s3:GetObject", "s3:ListBucket", "s3:DeleteObject" ],
    "Resource": [ "arn:aws:s3:::acme-backups", "arn:aws:s3:::acme-backups/*" ]
  }]
}

Restore points

A restore point is one complete, dated snapshot. The Backups - Restore screen lists them newest first, each showing its date, scope, size, destination and verification status. Restoring is a single click, but a careful one: the plugin stages everything before it touches your live site.

  1. Pick a point. Choose the restore point you want and decide whether to restore files, the database, or both. For an "undo a bad update" rollback, both is usually what you want.
  2. Stage & verify. The archive is downloaded from its destination to a staging folder and its checksum is re-verified. If the checksum does not match, the restore stops here and nothing on your site has changed.
  3. Swap. Files and database are swapped in together as a single operation, with the previous state held aside.
  4. Health check & rollback. The plugin loads the home page and admin to confirm the site is healthy. If the check fails, it automatically rolls back to the state held aside in the previous step.

Because the swap is atomic and a failed health check rolls back automatically, a botched restore can never leave you with a half-restored, half-broken site. Worst case, you end up exactly where you started and try a different restore point.

Restore as migration

Moving a site to a new host is just a restore onto a different server. Install Revolutionary Backups on the destination, connect it to the same off-site storage, and restore the latest point. During the swap, the plugin rewrites the site URL, file paths and serialized database references so the restored copy boots cleanly on its new home.

  • Search-and-replace done for you: old domain to new domain across posts, options and serialized data, without corrupting serialized strings.
  • Path rewrites: absolute upload and content paths are corrected for the new server layout.
  • Dry run option: preview which URLs and paths will change before committing the migration.

Integrity & alerts

Every archive is hashed with SHA-256 the moment it finishes uploading, and the hash is stored with the restore point's metadata. A scheduled verify job re-downloads a sample of archives and re-checks their hashes, so silent corruption from a flaky disk or a half-finished upload is caught proactively rather than during an emergency.

Alerts close the loop. Configure email recipients or a Slack incoming webhook under Backups - Settings - Alerts, and the plugin notifies you when a run fails, a run is skipped because cron never fired, or an integrity check trips. You can also opt into a quiet weekly digest summarizing successful runs and current off-site usage.

Tip: Send the failure alerts somewhere you actually watch, a team Slack channel beats a rarely-checked inbox. The whole point of off-site, verified backups is to learn about a problem on your terms, not in the middle of an outage.

WP-CLI

Every action in the dashboard is also available from the command line through the wp revbackup command, which makes Revolutionary Backups easy to wire into deploy scripts, CI pipelines and system crontabs.

# Run a full-site backup now and ship it off-site
wp revbackup run --scope=full

# List recent restore points with their verification status
wp revbackup list --limit=10

# Restore a specific point (files + database) without prompts
wp revbackup restore 4821 --scope=all --yes

# Re-verify the integrity of every stored archive
wp revbackup verify --all

Running the backup from a system crontab is the most reliable way to guarantee scheduled runs on low-traffic sites, since it does not depend on a visitor triggering WordPress cron:

# m h  dom mon dow   command
0 2 * * *  cd /var/www/acme && wp revbackup run --scope=full --quiet

Hooks & filters

Developers can hook into the backup lifecycle with standard WordPress actions and filters. Two of the most useful are shown below.

Use the revbackup_complete action to run custom logic after a successful backup, here we ping an external monitor so a missed run shows up on a status dashboard:

add_action( 'revbackup_complete', function( $backup ) {
    if ( 'success' !== $backup['status'] ) {
        return;
    }
    wp_remote_get( 'https://hc-ping.com/your-uuid' );
}, 10, 1 );

Use the revbackup_exclude_paths filter to add or remove file patterns from every backup, for example skipping a large, regenerable export folder:

add_filter( 'revbackup_exclude_paths', function( $paths ) {
    $paths[] = 'wp-content/uploads/exports';
    $paths[] = 'wp-content/cache';
    return $paths;
} );

Other commonly used hooks include revbackup_before_run, revbackup_failed, revbackup_before_restore, revbackup_after_restore, and the revbackup_destination_args filter for tuning upload behavior. See the full reference in the developer docs.

Troubleshooting

Most issues come down to cron, permissions, or destination credentials. Work through these first:

  • Scheduled backups never run: WordPress cron only fires on traffic. Set up a real server cron or run wp revbackup run from a system crontab. Check Backups - Logs for skipped-run notices.
  • Backup stalls or times out: lower the batch size under Settings - Performance and raise PHP max_execution_time. Backups resume where they left off, so a timeout does not corrupt the archive.
  • Upload to S3 fails: confirm the bucket name and region are exact, the key has the four permissions listed above, and your server's clock is correct, since S3 signatures are time-sensitive.
  • Restore health check fails: the auto rollback returns you to your starting state. Try an earlier restore point, and check the log for the specific page or query that failed the check.
  • Out of disk during a run: the staging folder needs free space roughly equal to your largest single backup. Move staging to a larger volume under Settings - Performance, or trim the file selection.

Tip: Enable verbose logging under Backups - Settings - Logging before reproducing a problem. The log records the exact step, file, or API response that failed, which turns most issues into a quick fix.

FAQ

Frequently asked questions

No. You connect your own S3, Google Drive, Dropbox or Backblaze B2 account, and archives go straight there. We never hold a copy and never meter gigabytes. Your storage bill is whatever your provider charges, which is usually pennies.

Yes. Restoring onto a new server is the built-in migration path. The plugin rewrites the site URL, file paths and serialized database references during the swap, so the restored copy boots cleanly on its new home with no manual search-and-replace.

Incremental backups and resumable, batched processing handle large sites comfortably. After the first full run, only changed files are captured, so nightly backups stay fast even on multi-gigabyte media libraries. Exclude caches and regenerable files to keep archives lean.

Each archive is hashed with SHA-256 on upload, and a scheduled job re-downloads and re-checks a sample of them. If a hash no longer matches, the restore point is flagged as unhealthy and you are alerted, so a silently corrupt backup is caught long before you need it.

No. The free version handles manual and scheduled local backups plus a basic restore from a local archive. The paid suite adds off-site destinations, incremental backups, one-click rollback-safe restore, integrity verification, and failure alerts.

Was this helpful?

Browse the rest of the documentation or see what is included in each plan.

Back to all docs