fix: a new server takes a backup after its first scan, and restarts to load the restored settings (#6786)
release / govulncheck (push) Successful in 16s
release / go (push) Failing after 49s
release / web (push) Successful in 1m9s
release / integration (push) Failing after 4m14s
release / Attach APK to the Release (tag releases only) (push) Canceled after 0s
release / Build + push container image (push) Canceled after 0s
release / Verify release artifacts (tag releases only) (push) Canceled after 0s
release / android (push) Canceled after 4m38s
release / Build signed APK (push) Canceled after 4m38s
release / govulncheck (push) Successful in 16s
release / go (push) Failing after 49s
release / web (push) Successful in 1m9s
release / integration (push) Failing after 4m14s
release / Attach APK to the Release (tag releases only) (push) Canceled after 0s
release / Build + push container image (push) Canceled after 0s
release / Verify release artifacts (tag releases only) (push) Canceled after 0s
release / android (push) Canceled after 4m38s
release / Build signed APK (push) Canceled after 4m38s
A one-off end-to-end run of the :dev image (scratch Postgres, generated FLAC files, no outbound network) found that the web restore, done the way docs/hosting.md describes, was refused with not_empty: a new server's startup scan fills the library before anyone signs up, and Restore counted tracks as occupied. The command-line restore passed the same run. - Restore now asks only that the instance has no accounts. The library the first scan found is replaced by the backup's (every foreign key into artists/albums/tracks cascades or sets null), and the restore locks the library tables so a running scan waits rather than adding to them. - Settings are read once at boot by about ten services, the library folders among them, so after a web restore the server ran on its defaults until restarted. The restore endpoint now answers, then asks the process to restart in place (syscall.Exec of the same binary, arguments and environment), which needs no container restart policy. The startup scan of the restarted server replaces the scan the endpoint used to start. - The restore form says Minstrel is restarting; the docs say a scanned new server still takes a backup. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
+6
-3
@@ -119,8 +119,9 @@ to the music as well.
|
||||
|
||||
### Restoring
|
||||
|
||||
A backup restores into a new Minstrel: an empty database, with no accounts
|
||||
and no library yet.
|
||||
A backup restores into a new Minstrel: one nobody has signed up to yet. If
|
||||
it has already scanned the music, that's fine; the backup's library takes
|
||||
the place of what the scan found.
|
||||
|
||||
1. **Put the music back first**, at the path the library had. The restored
|
||||
settings name the old library folders, and each track is found again by
|
||||
@@ -130,7 +131,9 @@ and no library yet.
|
||||
2. **Load the backup**, either way:
|
||||
- In the web app, choose **Create account**, then **Restore a backup**.
|
||||
Pick a `minstrel-….tar` file from the backup's `database/` folder and
|
||||
enter the setup token from the log (see *First account*).
|
||||
enter the setup token from the log (see *First account*). Minstrel
|
||||
restarts by itself once the backup is in, so it runs on the restored
|
||||
settings.
|
||||
- Or, with the server stopped, run
|
||||
`docker compose run --rm minstrel restore /backups/database/minstrel-20261102T030000Z.tar`,
|
||||
with the file on a volume the container can read. It brings the database
|
||||
|
||||
Reference in New Issue
Block a user