Forgejo restore across versions: pin the original release or upgrade during recovery?

Restore path and the version boundary

Forgejo's documented recovery workflow is manual: import the SQL dump, unpack the data directory and repositories, restore app.ini, fix ownership. The open decision is which Forgejo binary to run against the restored database. On first startup the server migrates the schema to the binary's version, and downgrades are unsupported — so restoring a dump from, say, an older LTS release onto the latest version is a one-way move that forfeits any rollback to the original release.

Constraints in our setup

Backups are component-wise (pg_dump, repository root, app.ini with SECRET_KEY and INTERNAL_TOKEN, APP_DATA_PATH), and each dump records the Forgejo version that produced it. LFS objects live on S3, outside the dump. Verification after restore would use forgejo doctor check plus functional tests (clone, LFS fetch, 2FA login). The documentation advises restoring with the same version that produced the backup but does not prescribe whether recovery should also be the upgrade moment.

Questions

• Is restoring onto the original pinned release first, verifying, then upgrading separately the safer documented practice, or do operators commonly combine restore and upgrade?
• If a restore onto a newer release fails mid-migration, is the pre-migration database recoverable only from the original dump, or does Forgejo keep any pre-migration snapshot?
• Does forgejo doctor check surface migration-related inconsistencies that would distinguish a clean upgrade-restore from a corrupted one?