Offsite encrypted backup
for Unraid

Why Unraid specifically needs offsite backup

Unraid's parity gives a lot of people a false sense of security. Parity is not a backup. It is a resilience mechanism against hardware failure of one or two drives. Everything parity protects against can happen again at a bigger scale, and everything parity does not protect against - most threats, honestly - has no mitigation inside Unraid itself.

Specifically, parity does not help with:

• Ransomware that encrypts files. Parity dutifully stores the encrypted versions.
• Accidental deletion by you or an application. Parity has no undo.
• Filesystem corruption on an array drive. Parity can rebuild bit-perfect garbage.
• Dual-drive failure during rebuild. A common scenario: one drive dies, parity rebuild stress kills a second drive before it finishes.
• Physical disaster. Fire, flood, theft.
• A bad flash drive (the Unraid OS itself). Not catastrophic if you have backed up the flash, catastrophic if you have not.

An offsite backup costs a small amount per month. Losing everything on a 40TB Unraid because of one of the above costs anywhere from hundreds of hours to uninsurable amounts of data.

The Unraid-native path: Restic in Docker

Unraid runs Docker natively. The cleanest offsite backup setup uses an official Restic container, pointed at your shares (read-only) and your /mnt/user/appdata, with the repository target pointing at an SFTP vault.

Install Community Applications first if you haven't. Then install a Restic container. A minimal working setup:

# Container configuration
Image:          restic/restic:latest
Network:        host

# Volumes
/mnt/user:/source:ro
/mnt/user/appdata:/appdata:ro
/mnt/user/system/restic-cache:/cache

# Environment variables
RESTIC_REPOSITORY=sftp:vaultuser@vault.servercrate.net:22150:/data
RESTIC_PASSWORD=your-repository-password
RESTIC_CACHE_DIR=/cache

# Command (set per-run, not as a default)
backup /source/critical-share /source/other-share /appdata --tag unraid-$(hostname)

The :ro on the source mounts is important. Your backup container should never be able to write to your data; it only reads.

Scheduling with User Scripts

Install the User Scripts plugin from Community Applications. Create a new script for nightly backup:

#!/bin/bash
# /boot/config/plugins/user.scripts/scripts/nightly-backup/script

# Stop key containers first so their data is consistent
docker stop nextcloud mariadb home-assistant

# Run backup
docker run --rm \
  --network host \
  -v /mnt/user:/source:ro \
  -v /mnt/user/appdata:/appdata:ro \
  -v /mnt/user/system/restic-cache:/cache \
  -e RESTIC_REPOSITORY="sftp:vaultuser@vault.servercrate.net:22150:/data" \
  -e RESTIC_PASSWORD="your-repository-password" \
  -e RESTIC_CACHE_DIR="/cache" \
  restic/restic:latest \
  backup /source/Documents /source/Photos /appdata \
    --tag unraid-nightly

# Restart containers
docker start home-assistant mariadb nextcloud

# Weekly: prune old snapshots
if [ "$(date +%u)" = "7" ]; then
  docker run --rm \
    -v /mnt/user/system/restic-cache:/cache \
    -e RESTIC_REPOSITORY="sftp:vaultuser@vault.servercrate.net:22150:/data" \
    -e RESTIC_PASSWORD="your-repository-password" \
    -e RESTIC_CACHE_DIR="/cache" \
    restic/restic:latest \
    forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune
fi

Set the schedule in User Scripts to 0 2 * * * (2am daily) and you have a working nightly backup.

What to back up, what to skip

Good candidates:

• Document shares - anything users actually create
• Photo originals - cannot be re-acquired
• appdata for all Docker containers - databases, configs, API keys
• VM images if you use them (stop the VMs first for a consistent image, or snapshot them)
• The Unraid flash config - you can also use the built-in "Flash Backup" to keep a copy in CA

Skip:

• Media you can re-rip
• Large VM disk images where you only need config, not state (back up the config separately)
• Scratch folders, torrent download dirs
• Transcode caches and temporary files

Backing up appdata safely

Backing up a running database usually corrupts the backup. Options for appdata, in order of quality:

1. Stop the container, back up, start it. Best and simplest. A few seconds of downtime for each app.
2. Use the app's own dump tool - mysqldump, pg_dump, Nextcloud's occ maintenance:mode. Back up the dump alongside the raw files.
3. Btrfs or ZFS snapshot the appdata pool, then back up from the snapshot. The container keeps running.

For 99% of home setups, option 1 is fine. Nextcloud, Home Assistant, qBittorrent, Plex - none of them mind a 10-second stop/start nightly. Calendar the restart window for 3am when nobody is using them.

The appdata specifically

Your Unraid Docker appdata is the glue that holds your entire setup together. Real example of what is often in there:

• Nextcloud users, contacts, calendars, file metadata
• Home Assistant zones, automations, integrations, history
• Plex libraries, metadata, watch history
• Sonarr / Radarr / Bazarr media management databases
• Vaultwarden password vaults
• Mariadb / Postgres databases behind all of the above

Losing a single TB media share is annoying. Losing appdata means a month of rebuilding and still ending up with something that is not quite right. Prioritize appdata in your backup.

Ransomware specifically

A real ransomware incident on Unraid typically looks like: SMB share exposed without enough isolation, attacker gets into Windows client, crypts all shares the Windows user can write to. Your Unraid parity happily stores the encrypted files.

Offsite Restic backup with snapshot history defeats this. The encrypted "ransomed" files get backed up as a new snapshot. Yesterday's snapshot still has the original files. You restore from yesterday, wipe the affected Windows machine, and keep moving.

To make this work, two things matter:

• Use Restic append-only credentials on the Unraid so that even a compromised Unraid cannot delete snapshots from the repo
• Keep at least 30 days of snapshots so you have room to discover the infection before it rolls off

Unraid flash backup

Your Unraid USB flash drive holds the config. If it dies and you have no backup, you have to rebuild from scratch. Use Unraid's built-in Settings → Flash Backup which uploads a backup to Community Applications' service, and separately back up /boot via your Restic job for a second independent copy.

Pointing Unraid Restic at ServerCrate

Once you have a ServerCrate vault, the credentials go straight into your Restic environment:

RESTIC_REPOSITORY=sftp:vaultuser@vault.servercrate.net:22150:/data
RESTIC_PASSWORD=your-repository-password

ServerCrate gives you SFTP-native storage backed by ZFS with zero-knowledge encryption. Your Unraid encrypts with Restic before anything leaves the box. The ServerCrate side cannot read your backups regardless of what happens on our end.