Nimble Backup protects the WordPress database and wp-content on a schedule or on demand. A run produces one archive per part of the site — the database, plugins, themes, uploads, and the rest of wp-content — which share a date and an id, so they can be restored together as one backup or one at a time.

Each finished backup can also be sent to storage you own: S3-compatible object storage, Dropbox, Google Drive or OneDrive/SharePoint. Nothing is sent anywhere until you set a destination up, and nothing passes through NimblePlugins at any point.

It also includes a migration workflow for moving a WordPress site between servers without FTP.

Backup and recovery

Create a backup on demand.
Schedule daily or weekly backups.
Choose what each run covers – must-use plugins, plugins, themes, uploads, the database – one archive per part, kept together as one backup.
Keep a configurable number of recent recovery points.
Build large backups in resumable chunks to reduce request-timeout and disk-I/O pressure.
Verify new archives before they are marked successful.
Download, restore or delete backups from WordPress admin – a whole backup, or one part of it.
Send each finished backup off-site to S3-compatible storage, Dropbox, Google Drive or OneDrive/SharePoint, and bring it back down again when you need to restore from there.
Create a verified pre-restore safety point before a destructive restore. Restore stops if that safety point cannot be created.
Keep backup archives when the plugin is uninstalled, so removing the plugin never silently removes recovery data.

Secure local storage

Working data is stored below wp-content/uploads/nimble-backup/. Backup and migration directories receive Apache and IIS deny rules plus non-index files, and archive filenames include a random suffix.

Local backups protect against application-level failures, bad updates and accidental changes. They sit on the same server as the site, and so are not a substitute for an off-site copy if the disk or the hosting account goes away — which is what the destinations above are for.

Migration

The Migration tabs create one package containing the WordPress database and wp-content, then transfer it directly from a source WordPress site to a destination WordPress site using a random, expiring token.

The destination validates the archive before extraction, rejects unsafe paths and symbolic links, and creates a verified local pre-import recovery point before overwriting existing data. The transfer token can be manually revoked as soon as the migration is complete.

Migration also supports different WordPress database table prefixes and performs serialization-safe source-to-destination URL replacement after import.

Nimble Security integration

Nimble Backup implements the public nimble_security_recovery_point_providers contract. When Nimble Security requires a recovery point before a destructive response action, Backup creates and verifies the recovery point synchronously. If it cannot do so safely, Security receives an error and can stop the destructive action.

No incident content, credentials or archive contents are exchanged through this contract. Only the recovery-point reference is returned.

Nimble Operations integration

Nimble Backup exposes its native Operations health provider through nimble_backup_operations_health contract 1.1. The provider reports aggregate backup, schedule, storage, integrity, restore and migration state without exposing archive contents, filesystem paths, credentials, destination details or transfer tokens.

Privacy

Backup archives stay on the WordPress installation unless you configure an off-site destination yourself, in which case a copy also goes to the account you named with the provider you chose. Nimble Backup never uploads anything to NimblePlugins, and no NimblePlugins cloud service is involved in backup, restore or migration at any point.

The optional migration feature only communicates with the source site URL explicitly entered by an administrator, authenticated by a short-lived token.

Where the plugin writes

Nimble Backup keeps everything it creates in one protected folder inside the uploads directory, resolved at runtime with wp_upload_dir(): backup archives, migration packages, database dumps and working files all live under uploads/nimble-backup/. That folder is created with an .htaccess file, a web.config file and an index.php silence file, so the archives are not reachable over the web.

Restoring a backup, and completing a migration, writes files back into wp-content. That is the purpose of the plugin: a backup that cannot be restored is not a backup. The WordPress plugin guidelines allow this for backup and migration plugins, and Nimble Backup keeps that write as narrow as it can:

Only wp-content is ever written. The plugin does not back up or restore WordPress core, and it never writes to wp-admin, wp-includes or the site root.
A restore or migration only ever runs from an explicit action by a logged-in administrator, behind a capability check and a nonce. Nothing is restored automatically, on a schedule, or in the background.
A backup run produces one archive per part of the site, each containing only what that part holds: a database dump, or a copy of one directory under wp-content.
The plugin never writes to its own plugin folder, to other plugins’ folders or to any theme folder outside a restore.
The two working files a backup needs – the database dump it builds before zipping, and the directory a package is unpacked into before a restore – are both created inside uploads/nimble-backup/ and deleted when the job finishes. A database dump is data, not something the server executes; it is only ever read back statement by statement through $wpdb during a restore the administrator started.
When an off-site destination is set up, each finished archive is also sent there. Nothing is ever read back from it on its own: bringing an archive back down happens only when an administrator asks for that archive by name, and it is written into uploads/nimble-backup/ like any other.

For developers

Another plugin can offer credentials this site already holds, so a destination need not be set up twice:

add_filter( 'nimble_backup_credential_sources', function ( array $sources, string $provider ) {
    if ( 'dropbox' !== $provider ) {
        return $sources;
    }
    $sources['my-plugin'] = array(
        'label' => 'My Plugin',
        // Called only when the administrator presses the button. Return this
        // plugin's own field names => values, or a WP_Error saying why not.
        'fetch' => static function ( string $provider ) {
            return array(
                'app_key'       => '…',
                'app_secret'    => '…',
                'refresh_token' => '…',
            );
        },
    );
    return $sources;
}, 10, 2 );

The callable is what keeps this cheap and private: drawing the button costs nothing, and the credentials are read at the moment somebody asks for them rather than on every page render.

Destinations themselves are pluggable the same way, through nimble_backup_destinations.

External services

Nimble Backup does not contact NimblePlugins. It sends nothing anywhere that you have not configured yourself.

Off-site storage is the one feature that contacts a service outside your own servers, and only after you choose one and enter its credentials. Four are available, none of them enabled by default and none of them contacted until you set one up:

S3-compatible object storage. No default and no suggested provider; the endpoint, bucket, region and keys are all yours to enter. Tested against Amazon S3, Backblaze B2, Wasabi, Cloudflare R2, DigitalOcean Spaces, Hetzner and MinIO. Requests go to the endpoint you entered. Terms: the provider you chose.
Dropbox – api.dropboxapi.com and content.dropboxapi.com. Used to hold your archives in a folder of your Dropbox. Terms: https://www.dropbox.com/terms and https://www.dropbox.com/privacy
Google Drive – oauth2.googleapis.com and www.googleapis.com. Used to hold your archives in a folder of your Google Drive. Terms: https://policies.google.com/terms and https://policies.google.com/privacy
OneDrive and SharePoint – login.microsoftonline.com and graph.microsoft.com. Used to hold your archives in a folder of your OneDrive or a SharePoint library. Terms: https://www.microsoft.com/servicesagreement and https://privacy.microsoft.com/privacystatement

The same answers apply to all four:

What is used for: sending a copy of each finished backup archive somewhere the server itself cannot take with it when it fails, and reading it back when you restore from there.
What is sent, and when: the backup archive, which contains a dump of your database and a copy of wp-content – including any personal data those hold. It is sent over HTTPS after a backup completes, whether that backup was started by hand or by the schedule. Nothing is sent when no destination is set up, which is the default.
What is never sent: nothing else. No telemetry, no site identity, no usage statistics, and nothing at all to NimblePlugins.
Whose account, whose app: Dropbox, Google Drive and OneDrive each need an app registered by you, with keys you enter yourself. This plugin ships no keys of its own and contacts none of these services until you have entered yours.
Whose terms apply: the provider you chose. Their terms of service and privacy policy are the ones that govern the copy, because it is your account with them.

There are two further outbound requests, and neither involves a third party:

Server-to-server migration. The destination site fetches the package directly from the source site over HTTPS, using the URL and token shown on the source site’s Export tab. You type that address in yourself, so the only host contacted is the one you chose. No copy passes through NimblePlugins.
A loopback request to your own site. Long backups are started in the background by having the site call its own home URL, so a slow job cannot be cut short by a reverse-proxy timeout. Nothing leaves the server.

Privacy

Backup archives contain whatever your site contains, including personal data in the database. They stay on your server unless you configure off-site storage, in which case a copy also goes to the bucket you named, under your own account with that provider. The plugin sends no telemetry, no usage statistics and no file contents to NimblePlugins, ever.

The secret key for off-site storage is stored encrypted, with a key derived from this installation’s own salts. Define AUTH_KEY and AUTH_SALT in wp-config.php if they are not already: wp-config.php is never part of a backup, so the stored key then cannot be opened using the contents of an archive. Without them WordPress keeps the salts in the database, which is inside every archive. The settings screen says which of the two applies to your site.

A migration token is valid for 24 hours from the moment it is generated, after which the download endpoint refuses it. You can revoke a token at any time from the Export tab. Migration packages are not deleted automatically once transferred, so remove the package from the source site when the migration is done.