Nimble Backup Wordpress Plugin - Rating, Reviews, Demo & Download
Plugin Description
Nimble Backup protects the WordPress database and wp-content with on-demand or scheduled local backups. 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.
- 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.
- 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
New working data is stored below wp-content/uploads/nimble-backup/. Backup and migration directories receive Apache and IIS deny rules plus non-index files. Newly-created archive filenames also include a random suffix.
Nimble Backup automatically moves compatible backup archives from the legacy nimble-migration-backups directory into the new protected backup directory. Existing 1.40.x settings are migrated into the new nimble_backup_* namespace, schedules are re-armed under the new package, and public Security/Operations contracts remain compatible.
Local backups protect against application-level failures, bad updates and accidental changes. They are stored on the same server and therefore are not a substitute for an independent off-site copy if the entire server or disk is lost.
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 remain on the WordPress installation. Nimble Backup does not upload backup contents to NimblePlugins.
The optional migration feature only communicates with the source site URL explicitly entered by an administrator. A short-lived token authenticates that site-to-site package transfer. No third-party NimblePlugins cloud service is required for backup, restore or migration.
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 package contains exactly two things: a database dump and a copy of 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 off-site storage is configured, the finished archive is also sent to the bucket you named. Nothing is read back from it automatically.
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 enter its address and credentials:
- What it is: any S3-compatible object storage you choose. There is 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.
- What it is used for: sending a copy of each finished backup archive somewhere the server itself cannot take with it when it fails.
- 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 the feature is switched off, 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 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.
Screenshots
Backup and Restore: the schedule, how many backups to keep, an on-demand backup and the restore points already saved. The size figures come from the site itself, so you can see what a backup will have to move.
Export on the source site. One package containing the full database and wp-content, ready to be pulled by the destination site.
Import on the destination site. The package is pulled directly from the source site over HTTP with the URL and token shown there, so nothing is downloaded or uploaded by hand.
