Backup and Disaster Recovery for Plex, Sonarr, Radarr, Tdarr, Prowlarr, and SABnzbd

A practical disaster recovery guide for backing up the important details of a Plex and Arr homelab without trying to duplicate the entire media library.

Rights and lawful use: Back up 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.

Who this is for: This guide is for media-stack administrators who need to rebuild Plex, Sonarr, Radarr, Prowlarr, SABnzbd, and Tdarr without duplicating an entire library. It focuses on app databases, host mappings, Compose files, secrets handling, restore order, dated archives, and evidence from an isolated recovery check.

Back Up the Rebuild-Critical Details

Most homelabs cannot easily back up the entire media library. That is understandable. The smarter target is the important rebuild information: app configs, databases, quality profiles, custom formats, lists, API integration placeholders, compose files, service notes, mount definitions, scripts, cron jobs, and restore order. Those details are small, but they are what turn a crash from a multi-week rebuild into a controlled recovery.

What to Back Up

  • Plex: database, Preferences.xml, metadata if space allows, plug-in support databases, and server identity-sensitive files.
  • Sonarr: config directory, database, backups, quality profiles, indexers, download clients, tags, naming, and root folder records.
  • Radarr: config directory, movie database, custom formats, profiles, lists, exclusions, tags, and root folder records.
  • Prowlarr: indexer definitions, app sync settings, tags, proxies, and API configuration.
  • SABnzbd: sabnzbd.ini, server definitions, categories, folder settings, tuning settings, and API key placeholder notes.
  • Tdarr: server config, node config, flows/plugins, scripts, worker schedule, review report scripts, and cache path notes.
  • Host: docker compose files, systemd units, fstab or mount units, backup scripts, cron entries, and restore notes.

What Not to Put in a Shared Backup Bundle

A blog download or portable script bundle should not contain live API keys, passwords, private IPs, tokens, hostnames, or personal paths. Use placeholders such as YOUR_PLEX_TOKEN, YOUR_RADARR_API_KEY, and YOUR_NAS_PATH. Your private backup stored on your NAS can contain secrets if it is protected, but any public article bundle should be sanitized.

Recommended Backup Destination

Store backups on the NAS or another system, not only on the local media server. A backup that lives on the same boot disk as the failed host is not a disaster recovery plan. If possible, use NAS snapshots or versioned folders so a bad automated backup does not overwrite the last good one.

/nas/backups/media-stack
  /plex
  /sonarr
  /radarr
  /prowlarr
  /sabnzbd
  /tdarr
  /host-notes
  /compose
  /mounts
  /scripts

Backup Frequency

  • Daily: Sonarr, Radarr, Prowlarr, SABnzbd, Tdarr configs and small databases.
  • Daily or weekly: Plex database depending on library activity.
  • After every change: compose files, mount units, custom scripts, reverse proxy config, and Tdarr flows.
  • Before updates: manual backup snapshot for apps being upgraded.

Restore Order

  1. Install or rebuild the base OS.
  2. Restore storage mounts and verify media paths.
  3. Restore Docker Compose files or systemd units.
  4. Restore application config directories while services are stopped.
  5. Start Prowlarr, then Sonarr/Radarr, then SABnzbd, then Plex, then Tdarr.
  6. Test indexer sync and download client connections.
  7. Test Radarr and Sonarr root folders.
  8. Test Plex library visibility.
  9. Test Tdarr cache and a single controlled transcode.
  10. Only then resume full automation.
Interactive restore order
Media Stack Restore Dependency Order

A rebuild works best when dependencies return in order instead of all at once.

  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.

Plex-Specific Notes

Plex has official guidance for backing up server data and restoring database backups created by scheduled tasks. The key point is that Plex data locations vary by operating system, and the database lives under the Plex Media Server data directory. Document your actual path. Do not wait until a failure to figure out where Plex stores its data on your host.

Arr-Specific Notes

Sonarr and Radarr both have built-in backup screens, but filesystem-level backup of the config directory is also useful when services are stopped. The built-in backups are convenient for app-level restore. Filesystem backups are useful for whole-host recovery. Use both if you can.

Validation and Evidence Are Part of Backup

A backup you never test is a hopeful copy. At least quarterly, restore one app into a test path or disposable container and confirm the archive opens, the database is readable, and the restore notes make sense. This does not need to be dramatic. A ten-minute restore test can reveal missing compose files, wrong paths, or backups that never included the file you assumed they did.

Minimum Viable Backup Checklist

  • All app config directories are copied to NAS.
  • Backups are timestamped or versioned.
  • Live secrets are protected.
  • Public bundles are sanitized.
  • Restore notes exist.
  • Mount definitions are included.
  • Custom scripts and Tdarr flows are included.
  • A test restore has been performed.

Beginner Walk-Through: Rebuild vs Restore

A restore means putting data back exactly where it was. A rebuild means creating a clean server and using your backups to recreate the important state. For homelabs, rebuild-friendly backups are often more useful than huge disk images. If you have app configs, compose files, mount notes, and restore order, you can rebuild on new hardware without needing the old machine to come back to life.

Technical Backup Validation

  • Check that backup archives are not empty.
  • Check that backup timestamps are recent.
  • Keep multiple versions.
  • Store backups away from the host being protected.
  • Encrypt or restrict backups containing live secrets.
  • Test restore into a disposable path or container.
  • Document version mismatches when restoring apps after major upgrades.

Restore Drill

Pick one app every month and pretend it failed. Find the backup, read the restore note, and confirm you know how to restore it. You do not have to complete a full production restore every time. The point is to keep the procedure familiar before an outage makes it urgent.

Database and Credential Safety

  • Stop services or containers before copying live SQLite databases when practical.
  • If you cannot stop a service daily, rely on each app built-in backup archive and copy those archives to the NAS.
  • Store backup archives on the NAS, but keep active application config on reliable local storage so apps do not depend on the NAS for every database write.
  • Encrypt or restrict backup shares because config folders often contain API keys, tokens, provider settings, and app passwords.
  • Keep at least one restore test note that proves the backup is more than a pile of files.

Implementation Playbook: Back Up Configs to NAS

Ubuntu Backup Script

sudo mkdir -p /usr/local/sbin /var/log/media-backups
sudo tee /usr/local/sbin/media-stack-backup.sh >/dev/null <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

exec >>/var/log/media-backups/media-stack-backup.log 2>&1

stamp=$(date +%Y%m%d-%H%M%S)
dest="/data/media-backups/$stamp"
mkdir -p "$dest"

items=(
  plex
  sonarr
  radarr
  prowlarr
  sabnzbd
  tdarr
  nginx-proxy-manager
  media-stack
)

for item in "${items[@]}"; do
  src="/opt/$item"
  if [ -e "$src" ]; then
    tar -C "$(dirname "$src")" -czf "$dest/$item.tgz" "$(basename "$src")"
  fi
done

cp -a /etc/fstab "$dest/fstab" 2>/dev/null || true
crontab -l > "$dest/root-crontab.txt" 2>/dev/null || true
find /data/media-backups \
  -mindepth 1 \
  -maxdepth 1 \
  -type d \
  -mtime +30 \
  -exec rm -rf {} +
EOF
sudo chmod +x /usr/local/sbin/media-stack-backup.sh

Cron Schedule

sudo crontab -e

# Run every morning at 3:15 AM.
# Logging is handled by the backup script or your system mail.
15 3 * * * /usr/local/sbin/media-stack-backup.sh

Docker Backup Rule

For Docker apps, the important folder is the host folder mapped to /config. Stop the container for the cleanest database copy when possible. If you cannot stop it daily, keep built-in app backups enabled and copy those backup archives to NAS.

docker compose stop sonarr radarr prowlarr

tar -czf "/data/media-backups/configs-$(date +%Y%m%d).tgz" \
  /opt/sonarr \
  /opt/radarr \
  /opt/prowlarr

docker compose up -d sonarr radarr prowlarr

Restore Test

  1. Pick one app, such as Prowlarr.
  2. Restore its backup into a temporary folder.
  3. Start a temporary container mapped to that restored config.
  4. Confirm the UI opens and indexer/app settings are visible.
  5. Destroy the temporary container after the test.

This guide is documentation-backed; TechGeeks did not run the example script or restore a named Plex, Arr, SABnzbd, or Tdarr environment for this revision. A completed archive does not prove that its database is consistent, that secrets are protected, or that a newer application version can restore it. Opening one interface does not prove root paths, imports, playback, notifications, GPU access, and automation are correct. Keep dated logs and restore evidence for the actual environment.

Security, Privacy, Legal, and Recovery Boundaries

  • Security: backups can contain API keys, tokens, passwords, private keys, and server identities. Encrypt or tightly restrict them and separate backup credentials from application credentials.
  • Privacy: databases, metadata, filenames, watch history, hostnames, addresses, and logs may identify people and viewing habits. Minimize collection and control retention and exports.
  • Legal: back up and restore only data and media you are authorized to retain, and account for copyright, privacy, employment, provider, and deletion obligations.
  • Recovery: keep multiple versions and at least one failure-independent copy, document version compatibility and restore order, and test in an isolated path before replacing production state.

Related TechGeeks and Series Navigation

This recovery installment turns the series' individual Plex, Arr, download, proxy, and Tdarr configurations into a rebuild sequence. Follow the linked service guides to identify each persistent /config path, then use the monitoring and wrap-up articles to confirm mounts, imports, playback, GPU access, and automation after restoration.

Related foundation: Building a Production-Grade Tdarr GPU Transcoding Stack for a Homelab.

References

Need help applying this?

Bring TechGeeks into the real environment.

If you are working through this on a live network, WordPress site, Linux server, AI workflow, or PisoWiFi deployment, send the context and we can help turn it into a practical plan.

Request helpGet field notesRecommended gear

4 thoughts on “Backup and Disaster Recovery for Plex, Sonarr, Radarr, Tdarr, Prowlarr, and SABnzbd

Leave a Reply

Your email address will not be published. Required fields are marked *