Choose the recovery point before the upgrade
Jellyfin documents database changes that can prevent an older server from using upgraded data. Treat the recovery point as the combination of a known server version and its corresponding data, rather than simply an older installer. This guide concerns your own media server; keeping a server backup does not grant access to any programme or other service.
Before maintenance, record the installed version, installation method, actual configuration and data locations, media mount paths, and the account that runs the process. Add the planned upgrade version and a short acceptance list. For a household library that list might include signing in, opening one music album, finding a saved collection and playing a short owned video. These are proposed checks, not observations from a tested installation.
Select a backup method that fits the installation
The built-in backup feature starts with Jellyfin 10.11. It can operate online, although the documentation recommends a quiet period without an active scan. A manual backup requires the server to be stopped before copying its data and configuration directories. Check your actual release and installation instructions before deciding which route to use; a container path and a host path can describe different views of the same storage.
For a built-in archive, the database is mandatory; Metadata, Subtitles and Trickplay are optional. Record that selection, including the restriction that the Trickplay option covers data not stored alongside media. The media files need their own protection plan. An archive stored on the same failing disk as the live service is a weaker recovery resource than a separately retained copy. Preserve the original archive and use a copy for rehearsal, so an unsuccessful restore does not consume the only recovery point.
Make restoration an explicit maintenance step
Reserve enough time for the restore decision, not just the upgrade. Decide who can stop the server, where the matching software can be obtained through the project's supported distribution, and which current directories would be preserved before replacement. A recovery copy that nobody can locate during an outage is difficult to use even when its contents are complete.
For a rehearsal, keep the restored instance isolated from the live server's writable data and ordinary clients. Use the same recorded version with the copied data, inspect the expected accounts and library entries, and verify media path assumptions. Record the result and any missing dependency. Do not run two processes against one live database as a shortcut to comparing them.
Use a clear keep-or-restore decision
After the upgrade, compare the acceptance list with the baseline. Distinguish a server starting successfully from a usable library: an unavailable mount or an account mismatch can leave a running process with an incomplete experience. Capture the symptom before changing unrelated settings, and keep the pre-upgrade copy until the agreed review period ends.
If restoration is required, follow the current instructions for your selected backup method. The documented web restore restarts the server; a manual recovery must respect stopped-process and matching-version requirements. Tell viewers about the interruption and retain the replaced data for diagnosis. A completed recovery record states which version is now live and which copy was used, without promising that every future upgrade can be reversed automatically.
Questions answered
Does the backup replace a copy of my media files?
No. Protect the original media separately and record which server data and optional assets the selected backup contains.
Can I downgrade by reinstalling the older server alone?
Do not assume so. Jellyfin documents version-related database migrations; retain the matching pre-upgrade data and follow its recovery instructions.
Sources & further reading
Official references for the subjects discussed. Service terms and device software can change.