From 7cb4a09837b875648b5a0c0fd3f6afaf1136d1cc Mon Sep 17 00:00:00 2001
From: Maurice <mauriceboe@icloud.com>
Date: Thu, 8 Oct 2026 12:27:10 +0200
Subject: [PATCH] docs(wiki): say which images refuse a newer database on
 rollback

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.
---
 wiki/Updating.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/wiki/Updating.md b/wiki/Updating.md
index b590cff19..bfd1307ac 100644
--- a/wiki/Updating.md
+++ b/wiki/Updating.md
@@ -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