RestorePilot Backup & Migration

Changelog

0.5.9

• Fixed: Master Reset’s “also delete stored backups” now actually deletes them. The fix released in 0.5.8 did not work on any site whose backups had been moved out of the uploads directory, which is every site that has run 0.5.7. The reset wipes the plugin’s settings before it deletes the backups, and the setting it wipes is the one recording where the backups were moved to — so by the time it went to delete them, nothing knew where they were. It reported success regardless. Uninstall was not affected and has worked since 0.5.8. If you have run a Master Reset with that box ticked since updating to 0.5.8, your backups are still on the server, in a restorepilot-private-storage directory beside your WordPress folder; running the reset again on 0.5.9 will remove them, or you can delete that directory yourself.

0.5.8

• Fixed: deleting the plugin now removes your stored backups, and Master Reset’s “also delete stored backups” now actually deletes them. Moving backups out of the uploads directory in 0.5.7 left both of these looking in the old place, so archives were kept while the plugin said it had removed them. Master Reset even wrote “Stored backups were deleted at the operator’s request” into the log while leaving every one of them on disk. A backup contains your whole database, so a copy left behind on a site you have handed over or deleted the plugin from matters. A storage directory you set yourself with RESTOREPILOT_STORAGE_DIR is never removed by either, because it is yours rather than the plugin’s.
• Security: large backup downloads are checked on every request instead of being placed at a secret web address that a scheduled cleanup deleted six hours later. Where WP-Cron is disabled or the site is quiet, that address kept working. Downloads are resumable, so an interrupted transfer continues rather than restarting. If your host cuts off long downloads, split the backup into volumes, or add define('RESTOREPILOT_DIRECT_DOWNLOADS', true); to wp-config.php to restore the old behaviour.
• Fixed: a restore now refuses a backup in the old single-document format that is too large for your server’s PHP memory limit, and says what to do about it, instead of accepting it and running out of memory part-way through with the site already in pieces. Backups taken by any recent version stream and are unaffected.
• Fixed: the files a restore needs in order to be resumed or monitored are now written and checked properly. They are the only record that survives the moment a restore replaces the database, and a failed write was previously ignored, which could leave a restore that could not continue and whose progress could not be read.
• Fixed: the confirmation dialogs now behave like dialogs. Keyboard focus stays inside them, Escape closes them, and focus returns to the control that opened them; the page behind can no longer be reached with the keyboard or a screen reader.
• Fixed: when a restore has to invent an administrator email address because none was usable, that address is now valid on sites whose address has no dot in it, such as a local development install at localhost.
• Changed: the plugin’s own description, privacy text and FAQ now describe where backups are actually kept and what is removed when you delete the plugin.

0.5.7

• Security: your backups are no longer kept where the web server can hand them out. They were stored under wp-content/uploads, protected by an .htaccess file — which Apache honours and nginx ignores completely. On nginx, which is what most managed WordPress hosting runs, a backup could be downloaded by anyone who knew or guessed its address; the only thing standing in the way was the filename. A backup contains your whole database, including every user account and password hash. Backups are now kept in a directory beside your WordPress installation, which your site has no web address for, and existing backups are moved there automatically the next time you open the plugin. Downloading through the plugin is unchanged and has always required you to be logged in as an administrator.
• Added: where your host does not allow a directory outside the site to be created, backups stay where they are and RestorePilot now says so in the log instead of assuming the .htaccess protected them. It checks by placing a file in the backup folder, requesting it over the web, and reporting what came back.
• Note: the move copies every file and verifies it has arrived before changing anything, and only removes the originals once the whole set is safely in place. If it cannot finish, nothing is changed and your backups stay exactly where they were.

0.5.6

• Fixed: the manual installation instructions in the repository README left out the includes/ directory, which the plugin loads eighteen files from. Anyone following them got a fatal error instead of a working plugin. Installing through WordPress was never affected.
• Fixed: a restore now enforces its own limits by looking at the backup rather than by believing what the backup says about itself. The number of database tables was checked against a figure the archive declared, so an archive that understated it could grow the restore’s working set until PHP ran out of memory. Tables are counted as they are read now, and an archive that unpacks to more than two hundred times the space it occupies is refused before anything is written to disk. A single database record longer than 64 MB is also refused rather than read whole. These protect against a damaged or crafted archive; a backup this plugin produced is unaffected, and reading the database export is now faster than before.
• Fixed: when Master Reset is asked to remove must-use plugins, anything it cannot delete is now named in the result. It previously reported only how many it had removed, so a file left behind was invisible while the reset still described the site as clean. A must-use plugin loads on every request, so one left behind is still running.
• Changed: development and test material is now excluded from the released package by an explicit list of what may be included, with the contents checked on every commit rather than at release time. No release has ever contained it; this makes that a property of the build instead of something remembered by hand.

0.5.5

• Fixed: a restore could stop partway with a “Duplicate entry” database error, and sometimes then report that a table was missing. When a restore continues in the background it may be picked up by two workers at once — one sent directly, one from the scheduled fallback — and both would write the same rows to the same temporary table. A row that has already been written is now recognised as such and the restore carries on, rather than treating it as a failure. Every other database error still stops the restore, and the log records when a table was written twice. This affects 0.5.3 and 0.5.4; whether it happened depended on timing, and it became more likely the larger the site. Note that this protection needs a table to have a primary or unique key to identify its rows by — a small number of plugin tables have neither, and a restore of those can still stop this way.
• Added: the password for a new administrator account can now be shown while you type it. That password is needed immediately after the restore, to sign in to a site whose address may have just changed, with no other administrator to fall back on — so a typo you cannot see locks you out.
• Fixed: after restoring a backup uploaded from your computer, the “Server backup path” box under Advanced settings was left holding an internal temporary filename, pointing at a file the restore had already deleted. Starting another restore without choosing a new file then failed. That box is now only ever what you type in it.
• Changed: Master Reset has moved out of the Status tab into a Danger Zone tab of its own. Everything in front of it is unchanged: the warning, the confirmation dialog, the acknowledgement, and typing RESET in full. Removing your stored backups and your must-use plugins both remain off unless you tick them.

0.5.4

• Fixed: cancelling a backup did not stop it. Cancel marked the backup cancelled, but the process doing the work never saw that. It was reading a copy of the job made when its turn started, and its own progress updates — which happen every few seconds — then wrote “still running” back over the cancellation. The backup carried on to the end. Cancelling now takes effect within about a second.
• Fixed: ending a stuck restore from the maintenance screen did not stop the restore. Ending it released the locks that keep two restores apart, but the process still doing the work carried on writing to the database for the rest of its turn, unaware. A restore started straight afterwards could therefore run alongside one that had not actually stopped, which is how a database ends up holding tables from two different backups. The work now stops within about a second of being ended. If you have ever ended a restore and immediately started another, compare your data against a pre-restore rollback point before trusting it.
• Fixed: a restore could lose its record of how far it had got when more than one process was involved, causing it to repeat work it had already finished. The same cause as the two above: each update to a job’s record was built on a copy that could be out of date, so one process could erase what another had just written.
• Added: Master Reset can now remove must-use plugins, which it previously always left in place — so a site it described as clean still had every one of them loading on every request. This is off unless you tick it, and the confirmation lists them by name rather than as a count, because some are installed by your host or by a site-management service and deleting those can break things you cannot reinstall yourself.

0.5.3

• Fixed: the duplicate-entry error during a restore that 0.5.2 claimed to fix was not actually fixed. The correction there re-read the restore’s saved position after taking the lock that makes a worker the only one running, but WordPress caches that read within a request, so it handed back the same stale copy it already had and two workers could still resume from the same place. It now reads past the cache.
• Fixed: starting a restore while another was still finishing could make the new one delete the tables the old one was still writing to, failing it with a missing-table error. Each restore now tracks its own scratch tables, and the cleanup that removes leftovers skips any restore that is still going.
• Fixed: Master Reset deleted RestorePilot itself, along with the other plugins it is meant to remove. Reorganising the code in 0.5.2 moved the check that told the reset which plugin folder was its own, so it stopped recognising itself. If you ran Master Reset on 0.5.2 the plugin was removed but your stored backups were not — reinstall RestorePilot and they will still be listed. Six other places that located the plugin’s own files the same way were corrected at the same time, including the one a restore uses to avoid overwriting the plugin while it is running.
• Added: Master Reset can now also delete RestorePilot’s own stored backups and rollback points, for when a site is being handed to someone else and should not carry copies of the previous content. It is off by default and has to be ticked deliberately, because those backups are the only way to undo a reset.

Older releases (0.5.2 down to 0.1.0) are listed in changelog.txt in the plugin’s
repository: https://github.com/srj2326/restorepilot/blob/main/changelog.txt