Ensembia/nextcloud-ng_backup
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 17 Wiki Activity

DR guide step 7 for rc2; changelog; version 0.9.8

Browse Source
This commit is contained in:
Dillard Blom
2026-10-18 01:45:39 +02:00
parent d8ef50732f
commit 7b735ea941
3 changed files with 42 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CHANGELOG.md
+29 -1
View File
@@ -9,8 +9,36 @@ instead carried by the app description, the git tag, the release, and this file.
## [Unreleased]
Fixes from a full disaster recovery test of a production instance (about 1 TB, Nextcloud
All-in-One onto a plain Nextcloud with PostgreSQL).
### Added
- `docs/DISASTER-RECOVERY.md`: step-by-step guide for when your server is gone.
- `occ backup:restore:full --install-apps` installs (from the app store) or enables the apps the
old server had enabled, before the restore starts.
### Changed
- A fuller app store description, ready for 1.0.0.
- Backups record the structure of every database table. A full restore creates tables that do not
exist on the new instance, for example those left behind by an app that was removed long ago or
is switched off, instead of stopping at the first one.
- A full restore no longer refuses when apps are missing: it restores their data and lists the
apps to install afterwards. `nextcloud-aio` is never required, so a backup of Nextcloud
All-in-One can be restored onto a plain Nextcloud.
- All problems are listed at once, with the app each missing table probably belongs to. For
backups made before this version, `--skip-missing-tables` leaves out tables whose structure is
unknown.
- A fuller app store description, ready for 1.0.0, and a note on paid restore help by Ensembia.
- README: switching the server to TCP BBR made backups over a long distance about 3 times faster.
### Fixed
- A full restore failed on foreign keys (for example those of the Mail app), because tables are
restored in name order. Foreign keys are now checked after all rows are loaded, before the
restore commits.
- `occ backup:target:add` without a key pointed to `backup:key:init`, which makes a new key that
cannot read existing backups. It now points to `backup:key:import` for a restore, and says that
connecting to a location with backups can take a while.
- Removing a location left its cached index in the database (tens of thousands of rows for a large
backup). It is removed with the location now, and once for locations that are already gone.
## [1.0.0-rc.1] - 2026-10-17