Back Up and Restore Jellyfin and the Media Automation Stack

This runbook separates the small, rebuild-critical state of a media server from the much larger media library, then shows how to prove that state can be recovered without touching production.

Rights and lawful use: Back up Jellyfin, Plex, Arr, SABnzbd, Prowlarr, and Tdarr configuration only for systems and media workflows you are authorized to operate. A recovery archive should preserve legitimate application state and restore notes, not become a way to retain, move, or share content without permission.

Quick Answer

Back up application databases, configuration, secrets, Compose files, mount definitions, encryption keys, and version records separately from bulk media. Use each application's supported backup method or stop it before copying live SQLite state, encrypt the archive, and keep at least one failure-independent copy. A completed archive is not proof of recovery: restore it on an isolated target with the recorded application versions before an upgrade or outage makes the test urgent.

What This Runbook Is Designed to Recover

Use this runbook to recover users, watch state, quality profiles, root folders, indexer links, download categories, transcode flows and host configuration without reconstructing them from memory. Bulk-media protection is a separate policy. The package, container, database and operating-system differences in the inventory determine the procedure; one generic script cannot establish a consistent backup of every stack.

Recovery tier	Examples	Backup method	Recovery priority
Tier 0: keys and access	Encryption keys, backup credentials, license information, administrator recovery codes	Encrypted, access-controlled copy with separate key custody	Required before any encrypted archive or protected service can be recovered
Tier 1: host definition	Compose files, environment files, systemd units, mounts, user/group IDs, firewall, DNS, proxy, cron, scripts	Versioned encrypted archive plus written inventory	Restore before application state
Tier 2: application state	Databases, settings, users, profiles, integrations, queues, history, metadata	Built-in backup or a cold, consistent filesystem copy	Restore after paths and permissions exist
Tier 3: derived data	Thumbnails, transcode cache, trickplay, downloaded metadata, temporary files	Include only when its rebuild cost justifies the space	Optional or later
Tier 4: media	Authorized movies, shows, music, photos, and home video	Independent storage policy based on replacement cost and legal obligations	Required for irreplaceable media; optional only when a lawful source can recreate it

Set a recovery point objective (RPO) and recovery time objective (RTO) for each tier. For example, an operator might accept losing one day of queue history but not the encryption key needed to open every backup. Those are policy examples, not TechGeeks measurements. Record the actual acceptable age and restore deadline for your environment.

Inventory the Authoritative State

Component	State to protect	Consistency rule	Restore note
Jellyfin	Data and config directories; database; selected metadata, subtitles, and trickplay; package or image version	Use the 10.11 built-in backup during low activity with no scan running, or stop Jellyfin for a full manual copy	Record the exact version and installation type; Jellyfin has no in-place downgrade mechanism
Plex	Main Plex Media Server data directory, Preferences.xml on Linux/NAS, platform-specific settings, scheduled database backups	Stop Plex before a whole-directory copy or database replacement	Restore ownership and keep archive files outside the live Plex data directory
Sonarr, Radarr, Prowlarr	Config directory, database, built-in backups, profiles, custom formats, tags, root folders, integrations	Prefer built-in backups; stop the service before a raw config-directory copy	Validate root paths, download client, indexer/app sync, and permissions
Seerr	settings.json plus SQLite or PostgreSQL data	Stop Seerr before copying SQLite unless using a supported snapshot or SQLite backup; use pg_dump for PostgreSQL	Validate users, requests, integrations, and notification settings
SABnzbd	sabnzbd.ini, categories, server definitions, folder paths, queue/history policy	Stop before copying active configuration, or use its supported backup workflow when available	Do not expose provider credentials or API keys
Tdarr	Server and node configuration, flows/plugins, schedules, scripts, cache path, library definitions	Stop server and nodes before a raw state copy	Validate one synthetic, authorized transcode and cache cleanup before resuming the queue
Host and network	Compose, .env, service units, UID/GID map, fstab or mount units, DNS, TLS, proxy, firewall, cron, GPU mapping	Archive after each material change	Restore mounts and identities before applications

Configuration backups are credential archives. They can contain API keys, password hashes, provider credentials, server identities, private hostnames, and user data. Do not place them in a public code repository or an unencrypted shared folder. Keep the decryption identity outside the protected host and test that an authorized recovery operator can retrieve it.

Jellyfin 10.11 Backup and Restore Boundaries

Jellyfin 10.11 added built-in live backup and restore. The current administration guide says the database is always included; metadata, subtitles, and trickplay are selectable. The server checks for at least 5 GB free in the backup folder, but those optional data sets can require more. The guide recommends creating the online backup during low activity while no library scan is active.

1. Open Dashboard > Backups and create a backup.
2. Include the database. Select metadata, subtitles, and trickplay only when they are part of the required recovery point and the destination has enough space.
3. Copy the resulting ZIP to encrypted, failure-independent storage. A backup inside the Jellyfin data directory is still lost with that directory.
4. Record the Jellyfin server version, image digest or package version, install type, config/data paths, archive checksum, and backup time.
5. For a full blank-host recovery drill, also take a manual copy of all data and configuration while Jellyfin is stopped. The 10.11 release notes describe built-in restore as same-system recovery, not a cross-operating-system or third-party-container migration tool.

Jellyfin applies database migrations when a newer version starts and does not provide an in-place downgrade. If an upgrade must be reversed, stop the newer server, restore a backup created before the migration, and start the recorded older version. Do not point an older binary at data already migrated by a newer one.

For a manual Jellyfin package backup, use the linked Jellyfin procedure with the actual data/config paths and installation version. Record whether the service was running, stop its writers and confirm they have stopped, then capture into a new private backup set. Encrypt through the approved backup tool, preserve a separate decryption identity, and verify the independent copy. On failure, mark the set incomplete and review service state; do not start an initially stopped server from an exit trap. Return only the intended services to their recorded prior state and verify any deliberate restart.

Acceptance result, not observed: Jellyfin is in its intended prior running or stopped state, and the new encrypted backup set and integrity manifest exist on the independent target. Check the manifest from that copy. Matching hashes establish integrity against the recorded hashes, not successful decryption, database consistency or recovery after host loss.

Plex and Arr Recovery Notes

Plex documents a backup of the main Plex Media Server data directory, with optional exclusion of the Cache directory on Windows and Linux. Keep the archive outside the live Plex data directory. The scheduled database restore procedure requires stopping Plex, moving the current database and any -shm or -wal files aside, copying the dated backup into place, restoring the normal filenames, and verifying that the Plex service account can read and write them.

For Sonarr, Radarr, and Prowlarr, keep the applications' own backup archives and an encrypted copy of the persistent /config directories. The built-in archive is the first choice for application-level recovery. A stopped filesystem copy supports whole-host recovery and preserves surrounding files that the built-in export might not own. Do not copy a live SQLite database with a plain recursive copy and assume consistency.

Plan a Consistent Encrypted Backup

Build the backup around an explicit writer and state inventory, not a guessed list of Compose service names. Include separate Tdarr nodes, Seerr, external databases and remote workers wherever they write the captured state. Record the actual bind-mount sources, named volumes, Compose project, application versions, encryption recipients and independent target. Keep the decryption identity separate. The following is a runbook to implement for that inventory, not an installer that overwrites a root-owned script.

Before stopping anything, verify the intended backup filesystem, free space, protected recipients, readable source paths and absence of a concurrent backup. Reserve a new private output set and record the currently running services. Pause automation, drain active copy/replace operations, and stop every writer to the captured state; verify the stopped state. Capture consistent application data and the matching runtime definitions, image/version records and protected secrets using the approved backup system. Validate encryption completion and hashes before accepting the set. A failed capture stays incomplete. Review recovery explicitly, returning only previously running services to service after checking the failure; keep workers paused if consistency is uncertain. Restore this set in isolation before scheduling the procedure.

The implementation must stop before capture when a required path, mount, key or writer check fails. A process being named in an inventory is not proof it has stopped. Keep error handling and the prior service state in the runbook so an archive failure cannot silently produce a successful report or start an unwanted service. The common cold copy creates downtime; application-supported backups can reduce that downtime, but still need independent copying and a restore drill.

Schedule only a reviewed implementation that has passed a manual backup, failure handling and isolated restore. Give it the minimum required privileges, prevent overlapping runs, rotate logs, and test that a failed or overdue backup notifies an owner. Do not overwrite an existing scheduled task or root script with an example.

Record the backup interval, accepted maximum age, retention policy and responsible operator alongside the scheduler entry. Test both a failed run and a missing run before relying on unattended operation. No schedule was installed for this revision.

Restore in Dependency Order

1. Isolate the recovery host from production DNS, proxy routes, webhooks, download providers, and automatic clients.
2. Install the base operating system and the recorded container runtime or packages. Do not start the application stack yet.
3. Restore users, groups, storage mounts, encryption keys, and stable paths. Verify read/write access with a non-production test directory.
4. Restore Compose files, environment files, systemd units, firewall rules, and local certificates. Replace production endpoints with isolated test values where necessary.
5. Verify checksums, decrypt archives into a staging path, inspect ownership, and copy state into the final directories while services remain stopped.
6. Start databases and infrastructure first, then Prowlarr, Sonarr/Radarr, SABnzbd, Jellyfin or Plex, Seerr, and Tdarr. The exact order can differ when your dependency graph differs.
7. Validate users, paths, permissions, integrations, and one synthetic authorized workflow. Keep full automation paused.
8. Record the achieved recovery point and time, then either destroy the test target or approve a controlled production cutover.

1. 1. HostOS + Users

   Rebuild the host, users, media group, packages, Docker, and GPU driver prerequisites.

2. 2. StorageMounts + Paths

   Restore /data paths, NAS mounts, marker files, cache directories, and permissions.

3. 3. ConfigCompose + App DBs

   Restore compose files, environment, app config folders, databases, and service units.

4. 4. Core AppsProwlarr / SAB / Arr

   Start source, download, and import apps before Plex/Tdarr broad processing.

5. 5. PlexLibraries

   Start Plex after media paths are correct so it does not see empty or wrong folders.

6. 6. TdarrAutomation Last

   Resume Tdarr only after imports, playback, API calls, and backups are verified.

Secret-bearing configConfigs and databases may contain tokens, passwords, provider settings, and private hostnames.

Restore testA backup is not real until at least one restore path has been tested.

Verify the Archive Before Restoring

Verify the backup set against its trusted origin and independent manifest before decryption. Stage decryption in a fresh private location on an isolated recovery host, not a reused production path. Before extraction, validate archive member names, types, links and expanded sizes with a maintained parser and resource limits. Reject traversal, unexpected special files and ambiguous paths. Use an unprivileged disposable extraction environment with no production mounts or secrets beyond the required recovery key; apply recorded ownership only to the reviewed staged copy through the restore runbook. A checksum match is not authorization to extract arbitrary archive content as root.

Acceptance result, not observed: the independent integrity check, decryption and archive review succeed; staged content matches the recorded file and identity plan. Any failure stops restoration. These checks do not establish database consistency or application recovery; continue with the tests below before enabling automation.

Validation and Acceptance Tests

Check	Acceptance result	Evidence to retain
Archive integrity	All recorded checksums pass from the independent copy	Command, UTC time, exit code, checksum file, storage location
Application startup	No database migration, lock, ownership, or missing-secret error remains	Version record and redacted startup log
Identity	Expected synthetic users and permissions exist; no production user is contacted	Redacted UI or API inventory
Storage paths	Test account can read the intended path and cannot write outside its scope	Read/write and safe negative permission result
Integrations	Prowlarr-to-Arr and Arr-to-download-client tests use isolated endpoints and succeed	Redacted connection-test result
Media service	One authorized synthetic item is indexed and direct-played; watch state can be updated	Client/server version and redacted playback evidence
Tdarr	One synthetic file completes the intended flow and the output hash is recorded	Flow version, job record, input/output properties
Recovery objectives	Measured backup age and restore duration meet the documented RPO and RTO	Start/end times and any gaps

Troubleshooting Failed Restores

• Database locked or corrupt: stop the application. Restore a supported built-in backup or a cold copy; do not keep retrying writes against a questionable SQLite file.
• Wrong owner or permissions: compare the fresh install's service UID/GID and directory modes with the archive. Correct the staged copy before starting the service.
• Missing API keys or passwords: keep automation disabled, retrieve the protected secret bundle, and rotate any credential that may have been exposed. Do not copy secrets into screenshots or tickets.
• Paths are wrong after migration: mount storage at the recorded path or use the application's supported path-remapping procedure. Confirm both container-side and host-side paths.
• Newer version rejects old state: install the recorded source version first, prove the restore, and follow the vendor-supported upgrade path. Do not repeatedly launch different versions against the same only copy.
• Jellyfin rollback fails: stop the newer server and restore the complete pre-upgrade data/config backup before starting the older version. A package downgrade without data rollback is not a Jellyfin rollback.
• Plex opens but libraries fail: verify the Plex data directory, database files, service ownership, server identity settings, and storage paths. A working UI does not prove playback.
• Apps start before mounts: stop them immediately, restore the correct mount dependency, and inspect for accidental writes into empty local mount points before resuming.

Rollback and Production Recovery

An isolated drill should never require a production rollback because it does not replace production state. If a real cutover fails, stop writes on both environments, preserve logs and the failed target, and return clients to the known-good endpoint. Do not synchronize the failed target back into the source. If the failure involves database migration, encryption keys, or uncertain filesystem integrity, work from copies and retain the original media and application state unchanged.

Recovery is complete only after the application-level tests pass, scheduled backups are running again, monitoring can report failures, the backup copy remains independent of the recovered host, and any temporarily exposed tokens have been rotated.

Security, Privacy, Legal, and Recovery Boundaries

• Security: encrypt backups containing secrets, use a dedicated backup identity with least privilege, restrict management interfaces to a trusted network or private VPN, and keep decryption keys outside the protected host.
• Privacy: databases, metadata, filenames, watch history, request records, hostnames, addresses, and logs can identify people and interests. Minimize collection, define retention, and redact reviewed evidence at original resolution.
• Legal: retain and restore only data and media you are authorized to use. Automation, Usenet, torrent protocols, remote access, and backup software do not change copyright, provider, privacy, employment, or deletion obligations.
• Recovery: parity, RAIDZ, snapshots, replication, and an archive on the same host are not independent backup. Preserve version records, key custody, off-host copies, and a tested blank-host path.

What the Available Evidence Does Not Prove

This revision is documentation-backed. TechGeeks did not create backup archives, restore a named Jellyfin, Plex, Arr, SABnzbd, Seerr or Tdarr environment, or measure RPO, RTO, archive size or duration. A checksum does not prove database consistency. Even a successful disposable restore would not establish offsite durability, media integrity, secret safety, DNS readiness or compatibility across every version and container image.

Related TechGeeks and Series Navigation

This recovery installment turns the series' individual media, automation, proxy, and processing configurations into a rebuild sequence. Use the service guides to identify each persistent config path, then use monitoring to prove mounts, imports, playback, GPU access, and automation after restoration.

• Plex Homelab Architecture: Storage, GPU Transcoding, and Library Design
• Media Server Storage Design: NAS, CIFS/NFS Mounts, Permissions, and Local Cache
• Prowlarr Setup Guide: Clean Indexer Management for Sonarr and Radarr
• Sonarr Homelab Setup Guide
• Radarr Homelab Setup Guide
• SABnzbd Performance Tuning for a Homelab Media Server
• Monitoring and Health Checks for a Plex and Arr Homelab
• The Complete Plex, Arr, and Tdarr Homelab Media Automation Series
• Docker Volume and Database Backup Guide

References

• Jellyfin: Backup and Restore
• Jellyfin 10.11.0 release notes
• Plex: Backing Up Plex Media Server Data
• Plex: Restore a Database Backed Up via Scheduled Tasks
• Emby: How to Back Up Manually
• Seerr: Backups
• Servarr Wiki
• NIST SP 800-184: Guide for Cybersecurity Event Recovery

Final Thought

Do not make the first full restore attempt during an outage. Inventory the small state that actually rebuilds the stack, protect its secrets, and prove one isolated recovery while the production server is still healthy.