56 Commits

Author	SHA1	Message	Date
dillard	51a4a67bc4	Heavy background jobs of other apps pause while a backup runs ... Reserved in Nextcloud's job list, so no app is turned off and a job that is running goes on. At most 6 hours in a row, then they get an hour; Nextcloud ends a reservation by itself after 12 hours, should the end of a pause never come. On by default, with a setting to turn it off.	2026-11-07 01:56:44 +01:00
dillard	36f2427e9a	Tell administrators about a location without a schedule ... A notification when a schedule is turned off, then a reminder: once a week while another location is backed up, every day when none is. The round trip now also checks the text of these notifications and of the one about names, and that one location never gets two runs.	2026-11-07 00:23:28 +01:00
dillard	e58b86fc48	A schedule per location, and locations backed up one after the other ... Off, once a day or every N hours from a time, each in its own time zone. Existing locations keep the time that held for all of them. A backup that has to wait shows as queued, and its restore point has the time it really began.	2026-11-07 00:04:00 +01:00
dillard	6540a9314a	A name a snapshot cannot hold gets a notification of its own ... Reported apart from unreadable files, with example paths and the advice to rename them, instead of advice about permissions. Start of the 1.1.0 plan in PLAN.md.	2026-11-06 23:38:40 +01:00
dillard	dd2e1af997	Roadmap: original modification time for all folders; guide: folders reported as updated	2026-11-06 18:08:34 +01:00
dillard	d96229f370	Release the locks of a killed restore when it runs again; legacy test without empty folders ... A killed restore left its leases for up to two hours, so the first backup of the recovered server was refused. A backup from before 1.0.3 records no empty folders: the test now expects that.	2026-11-06 17:34:33 +01:00
dillard	b14b16c66c	Empty folders in backup and restore, a full disk stops a restore, progress in the Bin ... - Record folders without files in the meta record of a snapshot and restore them (#27) - Errors writing to the restore directory stop the restore, also with --salvage - Resume: check the folder before skipping, clean temporaries in folders that are complete - Clean only read-ahead folders of our own; refresh the lease on skipped files - Drop tables a failed database restore created; keep --salvage from calling a restored database fresh - Retry a pack that fails to open on the storage (SMB) - Without cron, running backups take turns from the open page - Bin: read in parts with a counter and progress bar, show read errors, refresh when a run ends	2026-11-06 15:50:02 +01:00
dillard	e9592cb6c6	PLAN: findings from the reviews of 1.0.2, for 1.0.3	2026-11-06 11:57:08 +01:00
dillard	ecae6e9cdd	PLAN: 1.0.2 released; a branch per version	2026-11-06 11:29:57 +01:00
dillard	b625fe7666	A restore that stops at a file gone from the location points at --salvage; test a full restore with a damaged and a missing pack ... The DR test of 1.0.2 over SMB is done: result in PLAN, empty folders as a known issue (#27).	2026-11-06 10:27:41 +01:00
dillard	74bfa7052f	PLAN: DR test 1.0.2 over SMB, findings so far	2026-11-05 08:35:46 +01:00
dillard	3ec23a3072	PLAN: DR test for 1.0.2 over SMB; screenshots approved	2026-11-04 13:28:04 +01:00
dillard	4a395c75f2	PLAN: 1.0.2 status, DR test planned before the release	2026-11-04 04:22:40 +01:00
dillard	36a30732ad	Without system cron: warning and a backup that moves on while the page is open (#13); progress of the database phase; Bin tab ... - The admin page and backup:status warn when background jobs do not run on a system cron, or the cron stopped, with a link to how to set one up. - Without a working system cron, the open admin page moves a running backup forward through /api/tick, a short step per poll. - The database phase shows the tables dumped ("db: 47/183 tables"); a backup that has not moved for 15 minutes says it is waiting for background jobs. - The trash of restore points is on a tab of its own, Bin. - New screenshots; changelog and plan for 1.0.2.	2026-11-04 04:08:20 +01:00
dillard	f0293e6d01	Roadmap 1.0.2: the trash of restore points on a tab of its own (Bin)	2026-11-01 17:13:50 +01:00
dillard	f7c9894b78	PLAN: 1.0.1 released; new screenshots in 1.0.2	2026-11-01 12:59:49 +01:00
dillard	3694184674	Version 1.0.1: changelog, README status and roadmap	2026-11-01 12:03:19 +01:00
dillard	a11e6c7254	1.0.1: label for "Back up now", retention explained in the trash, occ times in the schedule's zone, single-file restore to a directory, leftovers of a stopped restore removed ... - Admin page: an optional label (at most 100 characters) for a backup started with "Back up now"; an (i) by "removed by retention policy" in the trash that explains what it means and until when the restore point can be brought back. backup:trash says the same below its list. - backup:status, backup:list, backup:trash and backup:browse show times in the zone of the daily schedule and name it, instead of the server's UTC. - backup:restore --to-directory of a file restored nothing: the path got a "/" appended. - A restore removes "<name>.ngb-restore-<hex>" temporaries that a stopped restore left in the folders it writes to. - Roadmap: the cron warning (#13), reading ahead from S3/SMB and --salvage move to 1.0.2.	2026-10-30 19:32:53 +01:00
dillard	3eec2e9554	Full restore on SQLite: take the write lock first, so another writer is waited for instead of "database is locked" ... SQLite in WAL mode starts a transaction as a reader; a write from another process between our first read and our first write makes our first write fail at once, whatever the busy timeout. The SQLite full-restore test now runs a second writer alongside the restore.	2026-10-29 03:06:05 +01:00
dillard	cdf0b70e25	Changelog: the admin page's single-line key field as the cause of #24; PLAN 1.0.1: #24, database locked at the start of a full restore on SQLite	2026-10-29 02:40:03 +01:00
dillard	08534975d7	Admin page: Docs tab with links to the how-to, disaster recovery guide and roadmap; drop "in beta" from the feedback line ... PLAN: 1.0.1 item 11 (Docs tab, done); 1.1.0 item 9: remove the feedback request in 1.1.0 or 1.2.0.	2026-10-27 11:23:34 +01:00
dillard	95e3dfcf6d	User restore by user id, backup:user:list (#22) ... backup:user:restore <location> <uid> only said "is not a recorded user export": the argument is the manifest path, which only backup:user:backup printed once. backup:user:list shows the exports again; a bare user id works when that user has exactly one export, otherwise the error lists them. The export is resolved before the replace confirmation. Fixes #22	2026-10-27 00:10:59 +01:00
dillard	7f4cae0e42	Roadmap: pin a restore point (1.1.0); PLAN 1.0.1: explain retention in the trash, time zone in backup:status	2026-10-25 02:40:13 +02:00
dillard	3a0f882a38	1.0.0-rc.6: changelog, SMB disaster recovery result in the README, 1.0.1 items (salvage mode, leftover restore files, single-file restore)	2026-10-24 00:40:51 +02:00
dillard	cd251cffb3	PLAN: SMB index reads one at a time (1.1.0)	2026-10-21 20:02:43 +02:00
dillard	0b4872599d	PLAN: the 1.0.1 cron PR closes #13	2026-10-21 19:51:57 +02:00
dillard	b7d09c9784	PLAN: 1.1.0 faster SMB (local and long-line measurements)	2026-10-21 09:27:15 +02:00
dillard	24686897c3	PLAN: DR tests across databases (integration for every crossing; S3 sim onto MariaDB, SMB sim onto SQLite before 1.0.0; nc01 onto MariaDB after)	2026-10-20 23:12:19 +02:00
dillard	315e83b847	PLAN: 1.0.1 progress in the database phase and a waiting notice, so a backup does not look stuck	2026-10-20 20:49:44 +02:00
dillard	6ed0a555cf	PLAN: label field next to Back up now (1.0.1); per-location schedules, every N hours, locations one after the other, editable notes (1.1.0)	2026-10-19 21:26:20 +02:00
dillard	221ed9dc17	PLAN: the cron warning says cron is needed for all backups, links to how to set it up, and that without it a backup started with the button only moves while the page is open	2026-10-19 21:18:23 +02:00
dillard	285153a968	PLAN: 1.0.1 cron warning says to keep the page open under AJAX, with a link to the Nextcloud docs	2026-10-19 21:16:23 +02:00
dillard	6c8a78f6bb	PLAN: 1.0.1 background jobs without system cron: warn, and let the open admin page move a backup	2026-10-19 20:41:11 +02:00
dillard	88b719879d	Release candidate 4 (app version 0.9.10): full restore over SFTP reads ahead; SFTP leg in the full-restore test	2026-10-19 03:51:21 +02:00
dillard	e0b79939f9	PLAN: 1.0.0 only reliability; 1.0.1 restore speed, cron warning, DR test with table structure	2026-10-18 23:19:18 +02:00
dillard	9e1378c6ab	PLAN: DR finding 16, restore during another server's cleanup	2026-10-18 21:57:17 +02:00
dillard	46eaceb928	DR guide step 9 from the test; PLAN: small DR test with rc2 passed	2026-10-18 08:51:00 +02:00
dillard	d8ef50732f	Full restore creates missing tables and suspends foreign keys; --install-apps; clearer messages ... Backups now record each table's structure in the dump manifest. The full restore creates tables that do not exist on the new instance (left behind by apps that were removed or are switched off), lists all problems at once, and no longer stops on apps that are missing. Foreign keys are not checked while rows are loaded in name order, and checked again before the restore commits (PostgreSQL: dropped and added back in the transaction). --install-apps installs or enables the apps that were enabled at backup time; --skip-missing-tables leaves out tables of older backups whose structure is unknown. nextcloud-aio is never required. backup:target:add without a key points to backup:key:import, and says that connecting can take a while. Removing a location drops its cached index; a migration removes the cache of locations that are gone. The full-restore test now also runs on PostgreSQL with Mail (foreign keys) and a disabled app.	2026-10-18 01:45:01 +02:00
dillard	5af712acc3	README: BBR for backups over a long distance	2026-10-18 01:26:27 +02:00
dillard	0924da48ac	PLAN: upload speed over long distances; DR guide container name	2026-10-18 01:15:34 +02:00
dillard	88477a1a9f	PLAN: SFTP restore speed over long distances; foreign keys valid after the restore	2026-10-18 00:59:06 +02:00
dillard	f633de59b4	PLAN: foreign keys block the database restore (Mail)	2026-10-17 23:15:13 +02:00
dillard	bbddc83f80	DR guide: background jobs, copying the kit, why not key:init; PLAN: app list and table structure in the backup	2026-10-17 21:38:55 +02:00
dillard	4d423825a0	PLAN: findings of the DR test, rc2 scope and a second DR test before 1.0.0	2026-10-17 21:29:51 +02:00
dillard	ff8619ae6b	PLAN: plan towards 1.0.0 and 1.1.0	2026-10-16 00:28:24 +02:00
dillard	b89b5b5fa6	Document known limitations for the beta and record the review backlog ... The open points from the pre-beta review are on the backlog in PLAN.md and listed as known limitations in the README; none block 0.9.0-beta or 1.0.0. The how-to warns against pointing a test server at a live location and explains that removing a slot does not revoke access.	2026-10-07 00:19:46 +02:00
dillard	614caf9f63	Document migrated- calendar names in the how-to; add backlog items	2026-10-06 16:59:45 +02:00
dillard	943c95bf07	Ask before installing user_migration; add the beta how-to ... backup:user:backup and backup:user:restore now ask the administrator before installing or enabling user_migration (or take --install-user-migration), so nothing changes on the server without consent. The restore warns that user_migration imports only its allowlisted app settings. Also: a clear error for unknown locations instead of a raw database message; prune reports the number of affected users, not the number of kept ones; and --user-last rejects values that are not whole numbers. Adds docs/HOWTO.md and updates the README and PLAN.md for the beta.	2026-10-06 16:57:56 +02:00
dillard	ba7f70e0f8	Rename per-user backup/restore commands to backup:user:backup and backup:user:restore	2026-10-06 03:51:35 +02:00
dillard	c9f82a79e4	Phase 2: retention for per-user exports (occ backup:retention --user-last) ... PruneService::userExportRetention()/setUserExportRetention(): a single, app-wide "keep the newest N" setting (default 3, same default as the snapshot policy's "last"), deliberately simpler than the full daily/weekly/monthly RetentionPolicy -- per-user exports are on-demand only (occ backup:backup:user, see the fold-out task about whether they ever join the automatic schedule), so there is no regular cadence yet to bucket by day/week/month. PruneService::applyUserExports(): groups a location's user exports by uid (read from each manifest's own 'time' field, the same field snapshot retention already reads), keeps the newest N per user, forgets the rest. No trash, unlike a snapshot: these are not yet the primary safety net the deletion delay protects. Runs under the same exclusive lock as snapshot retention. occ backup:retention gained --user-last=N; occ backup:prune now also applies it for every target it processes, reporting counts the same way it already does for snapshots and blob packs. Verified live against the dev rig (four real exports across four users, confirmed exactly the expected ones were kept/forgotten at two different --user-last values) and added coverage to tests/integration/user-roundtrip.sh (an account's manual export plus the automatic safety-export a replace-mode restore makes of it, pruned down to --user-last=2).	2026-10-06 03:18:14 +02:00