DadsFam Backups

Changelog

1.8.0

• Housekeeping release, prompted by the WordPress.org plugin review. Everything the plugin registers inside WordPress — its settings, its scheduled events, its hooks and its classes — now carries a full-length dadsfam_backups name instead of the old short dfb one, so it cannot collide with another plugin or theme on your site.
• Your settings, backup index, history, log and schedule are moved across to the new names automatically the first time the updated plugin loads. Nothing is lost, and your actual backup archives are never touched. A backup that happens to be running mid-update carries on.
• Two things change if you drive the plugin from outside the dashboard. The REST routes move from /dfb/v1/... to /dadsfam-backups/v1/..., and the WP-CLI command changes from wp dfb ... to wp dadsfam-backups .... Update any scripts or monitoring you have pointed at the old ones.
• Add-on hooks were renamed to match (for example dfb_capability is now dadsfam_backups_capability), so DadsFam Backups Pro must be updated to 1.5.0 at the same time. If one is updated without the other, Pro simply stops loading and tells you — nothing breaks.
• Every folder the plugin reads or writes is now resolved in one place through the WordPress functions for the job, which makes the plugin behave correctly on installs with a moved wp-content folder, a custom uploads path, or Windows-style paths.
• Fixed: the Plugin URI in the plugin header pointed at a page that no longer existed.

1.7.1

• New: the dashboard headline stats (Backups stored / Last backup / Last size) can now be enriched by add-ons via a new dadsfam_backups_dashboard_stats filter, so DadsFam Backups Pro can show what is stored off-site alongside what is on this server. On its own the free plugin looks and behaves exactly as before.

1.7.0

• Added: AI assistant support. If you connect an AI assistant to your site through an MCP plugin such as WPVibe, it can now check whether a backup is running, run the health checks, list and verify your backups, read the history and log, start or cancel a backup, and read or change your schedule and settings — all through the WordPress Abilities API (WordPress 6.9 and newer).
• Security: every AI action requires the same permission the plugin’s own screens use, and restoring a backup is deliberately not exposed to assistants — a restore overwrites your live site, so it stays a deliberate action behind the admin screens.
• Note: the AI interface reuses the plugin’s existing REST layer, so the same cooldowns, busy-checks and audit logging apply to an assistant exactly as they do to the API.
• On WordPress versions without the Abilities API, nothing changes and the plugin works exactly as before.

1.6.9

• Fixed: DadsFam Backups PRO was being left out of a restore. Only this plugin needs holding back during a restore, because it is the code doing the work; PRO is a separate plugin and is now copied across like any other, so a restored or cloned site arrives with it in place.

1.6.8

• Fixed: “Restore stalled — the server may be hitting a memory or time limit” while copying files. The time allowed for each step was only being checked between folders, not between files, so a single folder holding thousands of files (any uploads month, or a large plugin) was worked through in one go. That runs past the server’s time limit, the step is killed before its progress can be written down, and the next attempt begins that same folder all over again — so the restore could never get past it. The clock is now checked for every file, and a step that runs out of time stops exactly where it is and carries on from that same file next time.
• Added: if one individual file really is too large to copy within the time a step is allowed, the restore now stops and says what to change, rather than trying it over and over.

1.6.7

• Fixed: the checks that keep a restored site loading were running before the cache was cleared, so they were reading the site’s settings from before the restore. They could therefore leave a genuinely missing plugin switched on, or switch off one that was perfectly fine. The cache is now cleared first.
• Fixed: updating the plugin while a restore was already running could stop that restore with an error. A restore started on an older version now continues safely.
• Fixed: the free disk space a restore asks for was set too high and could turn away a restore that would have completed without trouble. It now asks for what is genuinely needed.
• Fixed: if a file could not be moved into place, the copy no longer removes the existing file first — the file already on your site is left exactly as it was and the problem is reported instead.
• Fixed: the check that spots a file too large to unpack now records each attempt as it happens, so it still works when a request is cut off by the server rather than by PHP.

1.6.6

• Added: before a restore unpacks anything, it now checks there is enough free disk space for the job. Running out of room partway through is one of the ways a file ends up half-written, and a half-written PHP file takes a site down. If there isn’t room the restore refuses to start and says how much is needed, so nothing has been touched.
• Fixed: if a single file in the backup is too large to unpack within the server’s time limit, the restore now stops and explains what to change, instead of quietly trying the same file over and over.

1.6.5

• Fixed: THE cause of restores that finished and then left the site showing a critical error. Unpacking the backup counted a file as done before it had finished writing it, so if that step ran out of time halfway through a file, the next step carried on from the following one – leaving a half-written file behind permanently. A half-written PHP file is a parse error, which takes the whole site down. Files are now only counted once they are completely written and checked, so an interrupted step simply picks the same file up again.
• Fixed: files are now written to one side and moved into place in a single step, both when unpacking and when copying into the site. An interrupted restore can no longer leave a half-written file where a working one used to be.
• Fixed: every unpacked file is now checked against the size recorded in the backup. If anything is short – which nearly always means the server ran out of disk space, or the backup is damaged – the restore stops immediately with a plain explanation, before your site has been touched.
• Fixed: a file that could not be read from the backup, or could not be written, was previously skipped in silence and simply went missing from the restored site. This now stops the restore and says which file and why.
• Added: any file that could not be written during the copy is now listed in the activity log as an error rather than passing unnoticed.

1.6.4

• Fixed: if a backup did not record which database table prefix it was made with, the restored tables were left under the old prefix – WordPress then could not find its own data and showed the installer, which looks exactly like the site needing to be set up again. The prefix is now read from the backup itself when it isn’t recorded, so the data always lands where this site expects it.
• Changed: the notes about files a restore deliberately leaves alone are now summarised in the activity log rather than listed one per file, so the log stays readable on sites with many of them.
• Changed: if a restored site’s theme is missing and the standard WordPress theme isn’t installed either, the site now falls back to whichever theme is available instead of being left without one.

1.6.3

• Fixed: a restore could finish and then leave the site showing nothing but a critical error. The cause was files that WordPress runs on every single request being copied in from the backup – a caching drop-in belonging to a plugin or service that is not on this site will bring the site down before it can even load the dashboard, leaving no way in to undo it. Those files are now left alone.
• Fixed: .htaccess and other server configuration files are no longer copied in from a backup. They belong to the server rather than the site, and one from a different host is a common cause of a blank error page. WordPress rebuilds .htaccess from your permalink settings.
• Fixed: the backup plugin no longer replaces its own files while it is in the middle of restoring, which could interrupt a restore part-way through.
• Added: after a restore, anything the restored database expects but that is not actually on the site is now handled instead of being allowed to crash it. Plugins whose files are missing are left switched off, and if the theme is missing the site falls back to a default one. Every one of these is written to the activity log so you can see exactly what happened and put it right.

1.6.2

• Changed: uploading a backup is now much faster. The plugin reads what your server actually allows and sends the largest pieces it safely can, instead of always sending small ones. On a server set up to allow it this cuts the number of requests dramatically – and since every request has to load the whole of WordPress before it writes anything, that overhead was most of the wait.
• Changed: each piece is now written straight to disk as it arrives rather than being held in memory first, so larger pieces do not increase memory use.
• Added: if a server refuses a piece for being too large (some setups cap this below the PHP settings), the plugin halves the piece size and carries on instead of failing.
• Note: to benefit, your hosting needs upload_max_filesize and post_max_size raised. The plugin adapts automatically either way – it will never send a piece your server cannot accept.

1.6.1

• Fixed: uploading a backup no longer starts again from zero when the connection drops. The upload is now given a name based on the file itself, so choosing the same file again picks up exactly where it stopped instead of throwing away what was already sent.
• Fixed: a brief connection glitch no longer cancels the whole upload and delete what had been received. The plugin now waits and retries the piece, up to six times, with a growing pause between attempts, and asks the server how much it already holds before carrying on.
• Added: pieces are now placed by position rather than counted in order, so a piece that arrives twice after a dropped connection cannot be written twice or land in the wrong place. The file is checked as a whole before it is imported.
• Added: if an upload is left unfinished, what was already sent is kept for three days so it can be resumed, then tidied away automatically.

1.6.0

• NEW: Pick exactly what to restore. The restore window now shows a checkbox for each part a backup contains — Database, Plugins, Themes, Uploads (media library), Other wp-content, and WordPress core — so you can bring back just what you need (say, only your uploads, or only plugins) instead of all-or-nothing. Leave everything ticked for a full restore or clone (behaviour unchanged); untick parts for a surgical restore. Only the parts a given backup actually contains are shown.

1.5.0

• NEW: One-click site cloning. Restoring a backup taken on another site already rewrote every URL to this install automatically — now the flow makes it obvious and effortless. Import a backup from another site and a big “Clone onto this site now” button appears the moment the upload finishes; the restore screen shows exactly which site the backup is a copy of and which address it will be rewritten to, and in the backups list a foreign backup’s action is labelled “Clone here”. No wp-config edits, no search-and-replace plugins — copying a live site onto a staging/test subdomain is genuinely a couple of clicks.
• NEW: A short, plain-English “Copying your live site onto this one?” guide right on the Import panel.
• NEW: “Scan for backups on the server.” Dropped a backup .zip onto the server another way — cPanel File Manager, FTP, or copied from off-site storage? One click finds it, adds it to your Backups list, and it’s ready to restore or clone. The Import panel now also shows the exact folder to drop files into. No more hand-placing files with no way for the plugin to see them.
• IMPROVED: Clearer wording across the restore/clone flow, and a stale code comment corrected — content URLs across all tables (including serialized data and JSON escaped slashes, the bare host and protocol-relative refs) have been rewritten on cross-site restores for some time; the docs now say so.

1.4.0

• NEW: Backup history — a permanent record of every backup this site has ever completed: when, how big, what was in it, its fingerprint, and (with Pro 1.4.0+) exactly which off-site destinations it was uploaded to. Until now, sites that upload off-site and then delete the local copy lost all memory of their own backups — the list emptied as fast as it filled, and “what backups do I have?” could only be answered by logging into your storage bucket. The archive may live in the bucket; the receipt now lives here. Kept for the last 50 backups, written by hooks only (the backup engine itself is untouched).
• NEW: GET /dadsfam-backups/v1/history — the history over the REST API, including a still_local flag per entry so you can tell at a glance which backups are on this server and which live off-site only.
• IMPROVED: GET /dadsfam-backups/v1/health now also answers the two questions that actually catch dying backup schedules: how old is my newest backup (last_backup_age_hours) and when is the next one due (next_scheduled_date, checked across both the free and Pro schedulers). A schedule that silently stopped shows up as a large age and no next run — visible in one call instead of discovered during a disaster.
• IMPROVED: backup listings over the API now include verified_at_creation — since 1.2.10 the engine opens and structurally checks every archive as it is finished and destroys any that fail, so a completed backup has, as a matter of fact, passed verification; the API now states it.

1.3.0

• NEW: a REST API, so backups can be driven and — more importantly — checked by something other than a human staring at the dashboard. Routes: GET /dadsfam-backups/v1/health (can this site even take a backup right now: zip extension, directory writable and protected, free space against the size of your last one), GET /dadsfam-backups/v1/status (what the engine is doing, read-only — it never advances the job), GET /dadsfam-backups/v1/backups and /backups/{id} (what actually exists on disk), POST /dadsfam-backups/v1/backup (start one), POST /dadsfam-backups/v1/backup/cancel, POST /dadsfam-backups/v1/verify/{id} (open the archive, check its structure, match its SHA-256 — the difference between “the plugin said it worked” and “the file has been opened and it is intact”), and GET /dadsfam-backups/v1/log. Every route requires a real capability; the default is the same manage_options the dashboard uses, and two new filters (dadsfam_backups_rest_capability_read, dadsfam_backups_rest_capability_write) let you split read-only monitoring from control.
• SECURITY: the API deliberately cannot restore, download, delete, or write settings. Those are the four routes an attacker would actually want — restore flattens the site, download IS the site plus the database, delete destroys your safety net before destroying you, and settings hold your off-site credentials (point them at someone else’s bucket and the site exfiltrates itself, nightly). They stay in wp-admin behind a human who had to log in. API responses are built from a field whitelist, so server paths and credentials cannot leak, and a future field cannot leak by accident either.
• The API does not tick the engine. The engine has been single-writer since 1.2.10 and drives itself from the page-view heartbeat and cron; adding an API driver would buy no speed and re-open exactly the concurrency class of bug 1.2.6–1.2.10 closed. Start a backup, then poll status.
• Starts and verifies are rate-limited (30s and 20s), and every API-initiated start, cancel and verify is written to the log with the account that did it — so on a client site you can tell an automated backup from a human one.

1.2.10

• CRITICAL: closed the last concurrency hole that made backups grow forever on hosts that kill long requests. When a killed slice left the engine lock behind, several waiting requests could all “steal” it in the same second — the takeover wasn’t atomic — and the resulting concurrent slices archived the same files twice, over and over (visible as the file count climbing past the real total and duplicate log lines). The takeover is now an atomic insert exactly one request can win; a RUNNING slice keeps the lock alive every 10 seconds so it can never be mistaken for dead regardless of how long its zip work takes; each slice’s work budget is clamped safely under the host’s kill wall so leaks stop happening in the first place; and the engine can no longer be driven from AJAX polling requests at all. Backups now have exactly one writer, always, on any host.

1.2.9

• The finalise fingerprint can now NEVER wedge a backup, on any host. Three guarantees: (1) the SHA-256 checkpoints its position and state every 32 MB WITHIN a call, so a host kill loses at most 32 MB of hashing instead of the whole call; (2) every call is capped by both time and bytes, so calls stay short enough to survive even brutal request limits; (3) a stall-breaker — if three consecutive calls make zero forward progress, the fingerprint is skipped with a clear warning and the backup COMPLETES anyway (verified and fully restorable; only the optional integrity fingerprint is unavailable). A finished backup always beats a perfect hash.

1.2.8

• The backup no longer swallows OTHER WordPress sites nested inside this site’s folder. On cPanel, a subdomain or addon domain’s document root often lives inside the main site’s directory; the file scanner descended into it and archived that entire second website too — inflating the backup by thousands of files and hundreds of MB, and dragging in that site’s unreadable files as warnings. The scanner now detects a nested WordPress installation (its own wp-load.php / wp-settings.php / wp-config.php) and skips it with a clear log line — each site backs itself up with its own copy of the plugin. Note: “a file could not be read and was skipped” warnings are the backup working correctly on permission-blocked files; the backup continues.

1.2.7

• CRITICAL: fixed backups growing forever (“Archiving files… N / N” climbing past the real file count, archive size ballooning). 1.2.6’s page-view heartbeat could run a work slice at the same moment as the dashboard’s own slice — the engine’s stages assume a single writer, so two concurrent slices archived the same files twice into one zip, over and over. All drivers (dashboard poller, page-view heartbeat, cron) now pass through one atomic engine mutex: only one work slice can ever run at a time, anyone else just reports status, and a mutex left behind by a host-killed request self-heals in 90 seconds. Cancel clears it too. Proven by tests that a heartbeat firing mid-slice can no longer advance the job, and that page views alone still drive a stalled backup to completion with a byte-correct fingerprint.

1.2.6

• Backups no longer depend on keeping the dashboard tab open and in the foreground. The engine’s work steps were only ever driven by the dashboard’s polling — switch to another tab, let the browser throttle a background tab (Brave and Chrome both do), close the laptop, or navigate to another admin page, and a running backup silently froze mid-stage forever. A page-view heartbeat now notices a backup that hasn’t moved for 20 seconds and advances it on the shutdown of ANY request to the site — a reader opening an article is enough — after detaching so the visitor feels nothing. An atomic lock guarantees two page views can never run the engine twice at once, and a lock left behind by a host-killed request self-heals in 90 seconds. Verified by tests where page views alone drive a stalled backup all the way to completion with a byte-correct fingerprint.

1.2.5

• Fixed large backups genuinely getting stuck at “Finalising archive — fingerprinting (SHA-256)…”. The whole finalise stage (fold the database in, verify, fingerprint) ran inside one request; on hosts that hard-kill long requests, a big archive made that request die mid-fingerprint and the next tick silently started the stage over — an invisible repeat-forever loop frozen on the same message. The finalise now runs as small persisted sub-steps that each execute exactly once, and the SHA-256 fingerprint itself is chunked and resumes across requests (with a live percentage in the progress message), so a killed request costs seconds instead of trapping the backup.

1.2.4

• The final stage of a large backup no longer looks frozen. After “Archiving files… N / N” the engine does several heavy steps that used to run silently — folding the database into the archive, verifying integrity, and SHA-256 fingerprinting the finished file (which alone can take a minute on a multi-GB backup). The progress bar now narrates each of these steps live instead of appearing hung at the file count.

1.2.3

• Added an extension point to the “backup completed” email so an add-on can replace the download button with an informational note. Pairs with DadsFam Backups Pro 1.3.5, which uses it so that when you have Pro’s “delete local copy after off-site upload” option on, the email no longer shows a download link that would stop working once the local file is removed — it tells you the backup is stored off-site instead. No change in behaviour when used on its own.

1.2.2

• Added a new dashboard extension point directly beneath the “Create a backup” card, so the Pro add-on’s off-site upload panel and progress bar now appear right under the backup you just made (previously it sat above the stats). Pairs with DadsFam Backups Pro 1.2.2.

1.2.1

• FIXED — the archiving progress could read past 100% on busy sites (e.g. “Archiving files… 26,137 / 17,296 files”) when files were added or changed while the backup ran. The counter now shows a sensible total and the final tally matches what was actually archived.

1.2.0

• The dashboard’s “Next scheduled” stat and the WordPress dashboard widget are now Pro-aware: when DadsFam Backups Pro’s advanced schedule is running the show, they display the Pro schedule’s next run (with a note explaining the free schedule is off on purpose) instead of a confusing “Off”.
• New extension points for the Pro add-on: a dashboard area after the quick stats (Pro’s new Off-site backups panel renders there), a filterable schedule stat, and extra status lines in the WordPress dashboard widget (Pro reports last off-site upload and any pending uploads).

1.1.0

• New: backup verification. Every new backup records a SHA-256 fingerprint of the finished file, and a Verify button on each backup checks the file exists, the archive structure is consistent, the manifest is present, and the fingerprint still matches — so you know a backup is genuinely restorable before you need it. Failed and passed verifications are written to the activity log. Older backups (made before this version) are still checked structurally.
• New: WP-CLI commands for people who manage sites from the server: wp dfb backup runs a full backup with live progress (ideal for real server cron, which is more dependable than visit-based WP-Cron), wp dfb list shows stored backups, and wp dfb verify <id> runs the integrity check.
• New: a “Send test email” button under Settings → Email notifications, so you can confirm delivery and see the email design without waiting for a backup to run.
• New: a DadsFam Backups widget on the WordPress dashboard — colour-coded backup health at a glance, last backup age/size, how many backups are stored, and when the next scheduled backup runs.

1.0.15

• New: the activity log now tracks download activity so you can keep an eye on your backups. It records when a secure email download link is created (and when it will expire), when a backup is downloaded through that link (including whether the person was logged in and their IP address), when a backup is downloaded from the dashboard (and by which user), when someone tries a link that has already expired or been used, and when a one-time link is used up. These appear right in Logs with colour-coded badges.

1.0.14

• Fixed: the secure download link in backup emails could say “expired or no longer valid” on the very first click. Some email apps quietly rewrite links and dropped part of the web address, so the link arrived incomplete. It is now a simpler single-piece web address that email apps leave intact, so it works on the first click. Links in older emails still work too.

1.0.13

• New: backup emails are now a clean, mobile-friendly HTML design instead of plain text — branded header, an at-a-glance summary of what was backed up, and a clear button.
• New: success emails can include a secure one-click download link straight to the backup file. No login is needed, it streams large backups reliably (with resume support for dropped connections), and it expires automatically after a set time — 24 hours by default — whether it was used or not. An optional one-time mode is available.
• The download link is protected by a random token (only a hash is stored on your server), and you can change the lifetime, switch on one-time mode, or turn the link off entirely under Settings → Email notifications.

1.0.12

• Fixed: emoji and other 4-byte characters (e.g. 🎉 and some Asian-language text) could be turned into “?” when restoring a backup. The backup now records the correct character set and the restore enforces it, so your content comes back exactly as it was. Verified character-for-character on a real WordPress restore.
• Fixed: after restoring a backup, a leftover “backup in progress” flag from the moment the backup was taken could block you from starting new backups. Restores now clear that flag, so a backup runs immediately afterwards.
• Added: if a backup ever stops unexpectedly (for example a server timeout), it is now detected and cleared automatically instead of blocking future backups.

1.0.11

• Migration URL rewrite is now bullet-proof. In addition to the full site address, the restore now also rewrites the bare domain (e.g. http://oldsite.com/…) and protocol-relative links, processed in the correct order so the most specific paths win. This fixes sites that live in a subdirectory and any content that hard-codes the domain, so a migrated site no longer keeps pointing assets at the old address. Verified with a real WordPress-to-WordPress migration across different table prefixes and URLs.

1.0.10

• Migration clarity. After a restore, the log now reports exactly what happened and flags anything that would break a migrated site: the URL change applied, whether the active theme (and parent theme) files are present, any active plugins whose files are missing, and a PHP version gap between the source and this server. The restore dialog also makes clear that copying a whole site needs BOTH database and files ticked.

1.0.9

• Backup integrity & completeness pass. Every finished backup is now verified before it’s marked successful — the archive must open and contain the database and metadata, or the backup fails clearly instead of leaving you with a bad file. Any file that can’t be read at archive time is now logged and counted (no more silent gaps), the completion log shows the exact file count, and a failed archive write (e.g. disk full) stops the backup with a clear message. Confirms a backup truly captured everything: database, plugins, themes, uploads and the rest of wp-content.

1.0.8

• Fixed “Could not open the file manifest for writing” after a file restore. The backup engine now recreates and verifies its working folder before every write (and retries if a restore removed or replaced it), and a restore no longer overwrites this site’s own backup folder. Backups are reliable immediately after a restore.

1.0.7

• Restore reliability overhaul. Fixed a bug where a restore step running out of time mid-statement could drop part of the database (the cause of incomplete restores). The restore engine now resumes only from completed statements, frees memory between statements, logs any skipped statements, saves progress mid-step, and — like the backup engine — survives server memory/time limits by resuming automatically or stopping with a clear message instead of hanging. Restoring now completes fully and predictably.

1.0.6

• Complete migration: restoring a backup from another site now also rewrites every site URL throughout the database (posts, options, widgets, theme …