2 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5.5	1e63f70bf7	fix: a media backup or restore cut off by a restart carries on where it stopped ... A media backup and a restore's file phase run as chains of 45-minute chunks, each queuing the next when it ends. A restart killed the chunk in flight, so nothing queued the next one; the run's row stayed "running", "Back up now" skipped it as already running, and only the 7-hour stall sweep ended it. - When the long-maintenance lane starts, it queues the next chunk of every media run still running and every restore fetching its files. - Each chunk writes its token to the run and hands it to the chunk it queues. A chunk queued by any other chunk is dropped (a killed chunk's message redelivered by acks_late, say), so a resume never doubles the chain; a chunk taken over stops at its next file. - The integration job installs postgresql-client when the CI image lacks it: the backup round trip in 375e7e2 runs the real pg_dump and pg_restore. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-11-07 14:53:57 -05:00
bvandeusenandClaude Opus 5.5	375e7e2eda	feat: restore a new install from the off-site bucket, database first, then every file ... Settings → Maintenance → Backups gains "Restore from the bucket": pick one of the bucket's dated dumps, type its confirmation, and FabledCurator saves the current database to the bucket, replaces it with the dump, migrates it to this version, then fetches every image and attachment back to the path its row records. Each file is checked against its sha256 on arrival and moved into place only then; a file already on disk is left alone, so "Fetch missing files" repairs a library that lost files without touching the database. - services/backup_restore.py: list/find/fetch dumps, migrate, keep this install's destination (the dump's sealed secret can't be opened here), library_files work list, restore_file (one fetch per sha, copies for duplicate paths, refuses paths outside /images). - restore_offsite_task: the database phase, then 45-minute file chunks with a heartbeat; a failed load leaves an empty migrated database and says why. The dump's own run row is marked ok, other runs then going "Interrupted". - backup_s3.get_file: sha/size check on arrival, ObjectMissing for a 404, download pacing. - backup_service: every dump leaves the credential table's rows out; restore_db reports pg_restore's last line, stops at the first error, ends other connections and waits at most 60 s for locks. - Backups and orphan repair wait while a restore runs; the stall sweep judges restores by heartbeat; restore runs are pruned to 20. - CLI: python -m backend.app.scripts.restore list|database|files. - README: backup and restore section; logins are in no backup. - Tests: a round trip through an in-process S3 bucket (tests/fake_s3.py) with real pg_dump/pg_restore, plus file, run, API and get_file cases. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-11-07 14:34:47 -05:00