Back to Changelog
v1.0.269
Durable WordPress backups: archives survive site deletion, restore-to-new flow
New Features
4- WordPress backups now survive uninstall. When a site is removed, its backups are moved to an Archived Backups library instead of being cascade-deleted. The tar.gz files remain on disk with all snapshot metadata preserved.
- New restore-to-new flow: archived backups can be deployed onto a freshly provisioned WordPress installation at any domain. Failure during restore automatically rolls back the new installation.
- New Archived Backups page in the WordPress Toolkit (panel - WordPress - Archived Backups). Lists archived backups with retention countdown, restore-to-new dialog, and atomic permanent-delete.
- New daily retention janitor (03:30) removes archived backups whose retention deadline has passed. NULL retention deadline means keep forever (operators configure wordpress.archived_backup_retention_days in panel settings).
Improvements
4- Backup engine reliability: database dump now streams directly with --single-transaction --quick, bypassing WP-CLI entirely. No more 5-minute timeout or RAM ceiling on large databases.
- Restore engine reliability: database restore now streams the dump directly into the bundled DB client, bypassing WP-CLI.
- Atomic backup deletion: removing a backup now deletes the tar.gz on disk AND the database row in one operation. Disk orphans cannot accumulate.
- Server-level backup system (services/backup) is unchanged by this release.
Bug Fixes
2- tar exit code 1 (file changed as we read it) is correctly treated as a warning instead of a fatal failure. Added --warning=no-file-changed for noisy live sites.
- The original wp-config.php is excluded from file restore so the freshly-provisioned target keeps its own database credentials and security keys.