.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
Nobody backs up Jellyfin until the week a major upgrade breaks a migration, which is why "jellyfin 10.10.7 backup" spiked as a search the moment 10.11 landed with its database overhaul.
Fair enough: the 10.11 migration rebuilt the server's internals onto a new database framework, it's one-way, and the users who could roll back were the users with a copy of the old data directory. Here's what to back up, the exact commands and the restore that proves your backup was real.
What needs backing up (and what doesn't)
Not the media. Your movies and music are the bulky part and the replaceable-from-source part; Jellyfin's irreplaceable state is small and lives in two places on a package install:
- /var/lib/jellyfin, the data directory: the database (in
data/jellyfin.dband friends), downloaded metadata and images, plugins and their configs. This is the one that matters. Users, watch history, library definitions, all of it lives here. - /etc/jellyfin, the config directory: networking settings, logging config, a handful of XML. Tiny, include it.
/var/cache/jellyfin is rebuildable cache (transcodes, image resizes); skipping it keeps backups dramatically smaller at zero cost. On Docker installs the split is simpler still: everything above lives inside whatever you mounted as /config and /cache, so the config volume is the backup target and the cache volume is the skippable one.
Stop the server first (the part guides skip)
Jellyfin's database is SQLite, and copying a SQLite file while the server writes to it produces a corrupt copy often enough to matter. A backup you can't restore is a rabbit's foot, so take the 60-second outage:
sudo systemctl stop jellyfinDocker: docker compose stop jellyfin. Yes, hot-backup techniques for SQLite exist; for a service whose users can tolerate a minute of downtime at 4 AM, cold copy is the version with no asterisks.
The backup itself
sudo tar -czf jellyfin-backup-$(date +%F).tar.gz \
/var/lib/jellyfin /etc/jellyfin
sudo systemctl start jellyfinDocker equivalent, from the compose directory:
docker compose stop jellyfin
tar -czf jellyfin-backup-$(date +%F).tar.gz ./config
docker compose start jellyfinA cautionary note on size: metadata images for a large library add up to gigabytes. That's normal, still worth including (re-fetching metadata for 2,000 movies takes hours and loses any manual fixes), and compresses reasonably.
Then get the archive off the machine. A backup on the same disk as the server shares the disk's fate; scp it to another box, object storage or at minimum a second volume. Cron the whole sequence weekly and you're ahead of ninety percent of self-hosters:
0 4 * * 1 systemctl stop jellyfin && tar -czf /backups/jellyfin-$(date +\%F).tar.gz /var/lib/jellyfin /etc/jellyfin && systemctl start jellyfin(Root's crontab, and note the escaped % signs, cron eats bare ones.) Add a second line to prune archives older than a month or the backup disk becomes the next incident. On our Jellyfin VPS plans the lazier belt-and-suspenders option also exists: the panel's snapshot and auto-backup slot captures the whole server, this directory included, though I'd still keep the tar habit because restoring one app from a whole-server image is the long way around.
Restoring
The restore is the mirror image, plus one permissions step people miss:
sudo systemctl stop jellyfin
sudo tar -xzf jellyfin-backup-2026-07-13.tar.gz -C /
sudo chown -R jellyfin:jellyfin /var/lib/jellyfin /etc/jellyfin
sudo systemctl start jellyfinThe chown matters when restoring onto a rebuilt server, where the jellyfin user's numeric ID may differ from the old machine's; wrong ownership here produces a server that starts and then fails in odd ways. Restore onto the same Jellyfin version the backup came from, then upgrade; restoring a 10.10 data directory into a 10.11 server works via the migration, but doing both steps at once means an error tells you nothing about which step failed.
And test the restore once before you need it. Spin a throwaway VPS or container, restore into it, confirm the login and a library render, tear it down. Twenty minutes, and it converts your backup from a hope into a fact. This is also the honest dress rehearsal for upgrades: restore yesterday's backup to a scratch box, run the upgrade there, and the 10.11-style migrations lose their power to surprise you.
The upgrade-day routine
Which brings us back to the search that sent you here. Before any major Jellyfin version jump, the routine is: fresh backup, read the release notes for migration warnings, upgrade, and keep the old backup for a couple of weeks rather than deleting it the moment things look fine (migration issues have a habit of surfacing on the first library scan, not the first boot).
Downgrading across a migration without a backup ranges from painful to impossible, and 10.11's database rewrite made that concrete for a lot of people. With the tar file on another machine, the worst upgrade outcome becomes a ten-minute restore instead of a rebuild, and you get to be insufferably calm about it.
Fresh installs have their own guide in our Jellyfin VPS install walkthrough; pair it with a restore and you've got server migration covered too.
