k1nq/TREK
1
0
Fork 0
mirror of https://github.com/mauriceboe/TREK.git synced 2026-10-23 15:36:33 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs(wiki): say which images refuse a newer database on rollback

Browse Source 
The rollback section promised that an older image refuses a migrated
database and names the pre-migrate copy. Only images from 4.4 on carry
that check. Going back to 4.3.x, the most common rollback today, gives
neither the refusal nor the pointer, so the copy has to be restored by
hand before the old image starts.
This commit is contained in:
Maurice
2026-10-08 12:27:10 +02:00
parent 28f6d30368
commit 7cb4a09837
1 changed files with 2 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
wiki/Updating.md
+2 -2
View File
@@ -80,7 +80,7 @@ See [Install-Helm](Install-Helm) for the full installation walkthrough and value
TREK runs any pending database migrations automatically at startup. No manual migration steps are required after pulling a new image.
Migrations only go forward. Once a newer TREK has migrated the database, an older image refuses to start on it, so going back means going back to a copy of the database from before the update.
Migrations only go forward, so going back to an older image means going back to a copy of the database from before the update. Images from 4.4 on refuse to start on a database a newer TREK has migrated. Images from 4.3.x and earlier do not check this: they start on the newer database without a warning, so restore the copy before you start one of them.
TREK takes that copy itself. Right before a startup applies pending migrations, it writes the database to `data/pre-migrate-<schema>-<time>.db` (next to `travel.db`, or next to the file `TREK_DB_FILE` names) and logs the path. `<schema>` names what the copy holds: `legacy-244` for a 4.3.3 install, or the last migration's number for a newer one. The newest three are kept (`TREK_DB_PRE_MIGRATE_SNAPSHOT_KEEP`). A restart with nothing to migrate and a brand-new install take no copy.
@@ -92,7 +92,7 @@ To go back to the previous image after an update:
2. Copy the `pre-migrate-…db` file over `data/travel.db` and delete `data/travel.db-wal` and `data/travel.db-shm`.
3. Start the previous image.
An older image that refuses a newer database names the copy it can run, if one is in the data directory. Uploads are not part of this copy; they are not changed by migrations. The copy is a safety net for the update, not a backup: keep taking backups as described in [Backups](Backups).
An image from 4.4 on that refuses a newer database names the copy it can run, if one is in the data directory. An image from 4.3.x or earlier neither refuses nor points at the copy, so for those, steps 1 to 3 are the only way back. Uploads are not part of this copy; they are not changed by migrations. The copy is a safety net for the update, not a backup: keep taking backups as described in [Backups](Backups).
## After the Update