Backup Restore Verifier Pro — Documentation

Guide to installing and using Backup Restore Verifier Pro for WordPress.

Current version: 1.0.6

1. Installation and requirements

1. Upload the backup-restore-verifier-pro folder to /wp-content/plugins/, or install the zip with Plugins → Add New → Upload Plugin.
2. Activate the plugin. Do not run it together with another edition of Backup Restore Verifier: if both are active a single notice asks you to deactivate one. Settings and backups are shared, so switching keeps everything.
3. Open Backup Restore Verifier and click Backup Now.
4. Configure destinations and options under Backup Restore Verifier → Advanced.
5. If DISABLE_WP_CRON is true, set up a real system cron that requests wp-cron.php, otherwise scheduled backups do not run.

Requirements: WordPress 6.3 or newer, PHP 7.4 or newer with the ZipArchive extension. Encryption needs libsodium with Argon2id; FTP needs the PHP ftp extension. Multisite is not supported.

2. Backups

A backup is one zip with a manifest and SHA-256 checksums. Choose which components to include: database, plugins, themes, uploads.

• Manual: Backup Now.
• Scheduled: hourly, twice daily, daily or weekly through WP-Cron.
• Chunked jobs: a job runs in short steps (20 seconds, or half of max_execution_time if that is lower) and resumes, so large sites do not hit time limits. Very large files can continue in the next step on every supported PHP version. PHP 8.0 and newer use the native hash functions; PHP 7.4 cannot save a native hash state between requests, so for files that cannot finish within one request it uses a built-in SHA-256 whose state can be saved. That path runs at roughly 9 MB/s on PHP 7.4 (measured), so a 1.6 GB file needs a few minutes per pass (backup, verification, restore); PHP 8 is much faster.
• One step at a time: only one request can advance a job at once. If you open the backup screen in a second tab or reload it, that tab waits and shows the current progress. If a step is interrupted (timeout, killed worker), the next step rolls the archive back to the last completed step and carries on.
• Self-check: before a backup is finished, every file in the archive is read back and compared with the checksum list, entry by entry and in order. Any difference stops the backup with a message that names the exact entry.
• Every long step resumes: encrypting the database dump, uploading to a remote destination, reading the parent index of an incremental backup, building and importing migration packages and preparing a migration all work in short steps that continue in the next request, on PHP 7.4 as on PHP 8. Progress is saved once at the end of each step, and anything an interrupted step wrote after that point is discarded.
• Retention: keep the last N backups (default 3). Oldest backups are removed after each successful backup.
• Failure alerts: optional e-mail through the normal WordPress mail function to the address you enter in Settings.

Backups are stored in wp-content/brverify-working/, which is protected by deny rules. On Nginx, add a rule that denies direct access to that folder.

3. Restore

• Restore is a job that you start and confirm; choose the components to restore.
• Before anything is applied the archive is checked: format, SHA-256 checksums and unsafe paths. The archive members and the checksum list must match one to one: an extra member without a checksum entry, a duplicated path, a missing member or a checksum entry without a member rejects the backup before any file or database change.
• Only members that passed the check are restored. Each restored file is compared with its validated SHA-256 before it replaces the live file, and the restore stops if the archive file changed after the check.
• An encrypted database is decrypted in steps across requests; it must authenticate to its last chunk before it is used.
• The site is put into maintenance mode and the affected components are snapshotted first. If the restore fails, the snapshot is put back.
• The plugin does not start a test copy of the backup. The check proves the archive is intact, not that the restored site works.

4. Destinations

Local protected storage is always used. You can add: S3-compatible storage (Amazon S3 and others), Backblaze B2, SFTP, FTP/FTPS, Dropbox, Google Drive, OneDrive and WebDAV. With several destinations selected, one backup goes to every one of them. A failing remote destination does not remove the finished local copy. Credentials are entered under Advanced; see External Services and Privacy below for what is sent and stored.

Large archives are uploaded in parts across requests: S3-compatible storage and Backblaze B2 use multipart uploads, SFTP and FTP send 8 MB slices (FTP servers must support resuming with REST), and Dropbox, Google Drive and OneDrive use their resumable upload sessions. If a request is interrupted, the next one continues from the last saved position. WebDAV has no standard resumable upload, so the archive is sent in one request; for very large sites on servers with short request limits, prefer another destination.

Endpoint safety (local and private addresses)

Addresses you enter for S3-compatible, Backblaze B2, WebDAV, FTP and SFTP destinations must be public. HTTP endpoints must use https:// on port 443 (or 80), without a user name or password in the URL. Every address the host name resolves to (IPv4 and IPv6) is checked, and localhost, private networks (10.x, 172.16–31.x, 192.168.x, IPv6 ULA), link-local addresses including the cloud metadata address 169.254.169.254, carrier-grade NAT and other reserved ranges are refused. The check runs when you save the settings and again before every connection. Redirects are not followed automatically: S3 requests never follow them, and WebDAV follows at most 3, checking each hop again.

For a test or development site that uses a local server such as LocalStack or MinIO, add define( 'BRVERIFY_ALLOW_PRIVATE_ENDPOINTS', true ); to wp-config.php. There is no switch for this on the settings screen, and a warning is shown there while it is active. Developers can limit the opt-in to specific hosts with the brverify_pro_private_endpoint_hosts filter and allow extra public HTTPS ports with brverify_pro_allowed_endpoint_ports. Do not use the opt-in on production sites.

5. Incremental file backups

In incremental mode only files changed since the previous backup are packed. The database dump is a full dump on every run. A restore needs the complete chain of backups; retention keeps a parent backup as long as a kept child needs it.

6. Site migration

Under Migrate: choose a backup, enter the target URL, then plan, dry run, confirm and run. URLs and paths are rewritten, including serialized and JSON data, and the table prefix can change. The existing site is snapshotted first and rolled back if the run fails. Migration packages (zip with manifest and checksums) can be exported and imported.

Export and import run in short steps while the Migrate screen stays open. Export checks every member of the backup against its checksum, then writes the package and its SHA-256. Import accepts only the four package files, checks the descriptor, copies the inner backup out while hashing it, and runs the same one-to-one archive check as a restore before the backup appears in the list. The prepared database of a migration is fingerprinted, checked again before the first statement runs, and must come from the database member that passed validation.

7. Database encryption

When switched on, the database dump inside each new backup is encrypted with libsodium (Argon2id key derivation, XChaCha20-Poly1305 stream).

• Files in the archive are not encrypted.
• The passphrase is not saved in the database. Scheduled backups read it from a constant or key file referenced in wp-config.php, so anyone who can read that file can decrypt that host's backups.
• A passphrase typed for a restore is kept, sealed, in a temporary transient for up to 15 minutes.
• A lost passphrase cannot be recovered by anyone: the encrypted database is gone. Files in the same archive remain readable.

8. Backups before updates

Optional. Takes a backup right before plugin, theme and WordPress core updates, with its own rules (update types, skip window, optional remote upload, optional block of the update when the backup fails) and its own retention.

9. External Services

The plugin contacts a service only for the feature you switch on. It sets no cookies and collects no usage statistics.

Backup destinations (only after you configure and select them)

Data flows from your site to the destination (the backup archive, a file name, and requests to list or delete archives) and back to your site when you restore, check or migrate from a stored archive. An archive is a copy of your database and the files you chose, so it can contain personal data of your users and visitors. The credentials you enter are saved in the WordPress options table without extra encryption and are included in the database part of every archive.

Service	Data sent
S3-compatible storage (for example Amazon S3)	Archive data, object names and list/delete requests to the endpoint and bucket you enter. Requests carry your access key ID and a signature computed with the secret key; the secret key itself is not sent.
Backblaze B2	As S3-compatible storage, through the S3-compatible endpoint you enter.
SFTP	Archive data, file names and list/delete requests to the host and port you enter, authenticated with the user name and the password or private key (the private key signs the login locally and is not sent).
FTP / FTPS	Archive data, file names and list/delete requests to the host and port you enter, with the user name and password. The connection is not encrypted unless you tick the FTPS option.
Dropbox (api.dropboxapi.com, content.dropboxapi.com)	Archive data, file paths and list/delete requests, plus the app key, app secret, authorization code and access/refresh tokens used to sign in.
Google Drive (oauth2.googleapis.com, www.googleapis.com)	Archive data, file names, the folder ID and list/delete requests, plus the client ID, client secret, authorization code and access/refresh tokens used to sign in.
OneDrive (login.microsoftonline.com, graph.microsoft.com)	Archive data, file paths and list/delete requests, plus the application ID, client secret, authorization code and access/refresh tokens used to sign in.
WebDAV	Archive data, file paths and list/delete (PROPFIND) requests to the URL you enter, with the user name and password (HTTP Basic or Digest).

Each of these services has its own terms and privacy policy.

10. Privacy and personal data

• What the plugin stores itself: settings (including the optional notification e-mail address and saved destination credentials), job and log rows (job type, status, file names, error messages). Log rows are not meant to hold personal data.
• Backup archives are copies of the site, so they contain whatever personal data the site holds. They stay in wp-content/brverify-working/ unless you add a remote destination. The newest 3 are kept by default (Settings → Retention).
• WordPress privacy tools: the plugin adds suggested text to the privacy policy guide and registers a personal data exporter and eraser. The eraser clears the notification address and the log rows that contain it, looking them up by the stored address. Existing archives are not rewritten.

11. Deleting the plugin

By default your settings, backup history and backup files are kept; scheduled events and transients are removed. Tick Delete all data when the plugin is deleted in Settings first to remove all plugin options, tables, user meta and the backup files.

12. Common questions

Does the plugin prove that my backup restores cleanly?

It proves that the archive is intact (checksums, format, safe paths). It does not start a copy of the site.

Does the plugin work on 32-bit PHP?

Yes, with a limit. On PHP 7.4 the resumable SHA-256 needs 64-bit PHP, so on 32-bit PHP 7.4 a file has to be hashed within one request, and 32-bit PHP cannot handle files of 2 GB or more at all. Use 64-bit PHP (the norm on current hosting) for large sites.

I used an earlier pre-release build under another name.

On first load the plugin moves the old options, tables and backup folder to the new names. Backups that pre-release builds made with database encryption turned on used a different header format and cannot be opened by this version; make new backups after upgrading.

13. Changelog

1.0.6

• Database restore and rollback can safely repeat the last statements after a killed request (rows are written as REPLACE into the freshly recreated table), so an interrupted restore no longer stops with a duplicate-row error.
• Migration packages are built and imported in short steps across requests (PHP 7.4 and 8). Export validates the backup member by member, hashes it, writes the package and hashes it. Import checks the package files and descriptor, copies and hashes the inner backup, then runs the step-by-step one-to-one archive check before the backup is added. A per-task lock and a single save point per step protect against overlapping or interrupted requests.
• Encrypted databases are encrypted during backup and decrypted during restore in steps across requests. Between steps the stream state is sealed with secret material derived from the passphrase; the passphrase itself is never written. Output from an interrupted step is cut back to the last saved point.
• Migrations copy or decrypt the database, rewrite it (with a saved output size, so statements cannot be duplicated) and fingerprint the prepared files across requests. The prepared database is checked before the first statement and must come from the validated archive.
• SFTP and FTP uploads go in 8 MB slices; Dropbox, Google Drive and OneDrive use resumable upload sessions, one request per call. WebDAV still sends one PUT.
• Incremental backups read the parent file index across requests. The package download sends the stored SHA-256 instead of re-hashing the file.
• 32-bit PHP limits are documented.

1.0.5

• Restore validation is strictly one-to-one: an archive with an extra member that has no checksum entry, a duplicated path (in the archive or in the checksum list), a missing member or a checksum entry without a member is rejected before any file or database change.
• Restore applies only validated members, checks each restored file and the database dump against the validated SHA-256 before use, and stops if the archive changed after validation.
• PHP 7.4: very large files now pause and resume across requests during backup, verification and restore (built-in resumable SHA-256, about 9 MB/s on PHP 7.4; PHP 8+ uses the native hash).
• The post-restore spot check skips files over 32 MB, which were already hash-checked while being restored.

1.0.4

• Fix: a backup could fail its own check with “Archive member does not match the checksum list” when two requests advanced the same backup at the same time (for example a second admin tab or a reloaded backup screen). Only one request can now run a job step at a time.
• Each archive entry’s data, directory record and checksum line are saved together, and an interrupted or repeated step is rolled back exactly, so entries can no longer be duplicated, dropped or reordered.
• Clearer error messages when the archive and the checksum list differ.
• Files whose names contain line breaks or other control characters are skipped with a log warning.
• PHP 7.4: the bundled SFTP library now uses a PHP 7 compatible version of its encoding dependency.

1.0.3

• Large sites: file discovery, packing, verification and restore run in small resumable steps; large working data is kept in protected working files; the archive writer supports files and archives over 4 GB.
• Failures record the real error (message, phase and file) in the job, the log and the failure e-mail.

1.0.2

• Removed the 007AJ verification client completely: no related screen, setting or stored data, no requests to 007aj.com and no update gating. The only outbound requests go to the storage destinations you configure.
• Code clean-up so WordPress Plugin Check reports no errors.

1.0.1

• Security: S3-compatible, Backblaze B2 and WebDAV endpoints use the WordPress safe HTTP API and are validated when saved and before every request (HTTPS only, public addresses only, redirects re-checked). FTP and SFTP hosts get the same private-address check. See Endpoint safety.

1.0.0

• First public release.

14. Support

E-mail admin@007aj.com.