nas-backup

Restic + autorestic configuration for backing up a Synology NAS to Backblaze B2. Clone this repo onto the NAS, drop in a .autorestic.env with the secrets, and wire two jobs into DSM's Task Scheduler.

Example install path used throughout this README: /volume1/tools/nas-backup. Substitute your own — the repo doesn't care where it lives, as long as DSM's Task Scheduler can cd into it when the jobs fire.

The installed versions, URLs, and checksums live as constants at the top of install.sh. To upgrade, bump the constants, commit, and re-run ./install.sh.

• restic — single Go binary, content-addressed, deduplicated, encrypted backup tool. Stores snapshots in a repository on some backend (B2, S3, local disk, SFTP, …).
• autorestic — YAML wrapper around restic. One config describes locations (what to back up) and backends (where to store it), then autorestic backup -a runs every location, autorestic forget -a --prune applies the retention policy and reclaims space.
• Encryption — the RESTIC_PASSWORD you pick encrypts the repo. Lose it and the backup is unrecoverable. Keep a copy in a password manager and/or on paper, off the NAS.

1. Create a private bucket (e.g. yourname-nas-backup). Lifecycle: "Keep only the last version of the file" is fine — restic manages its own history.
2. Create an application key scoped to that bucket with capabilities: listBuckets, listFiles, readFiles, writeFiles, deleteFiles.
3. Note the keyID and applicationKey — the applicationKey is shown only once.

Decide where on the NAS to put the repo. /volume1/tools/nas-backup is the running example — anything works. Install under a DSM shared folder (not a plain SSH-created directory under /volume1) if you want DSM's normal permission, snapshot, and Hyper Backup coverage to apply. Whether that shared folder is encrypted is independent of anything in this repo; if it is, the scheduled tasks below will simply no-op while the folder is locked.

SSH in as an admin user, then:

Fetch the repo as a tarball with curl + tar (both present on DSM):

# Download into /volume1/tools/nas-backup (under the shared folder from step 1).
mkdir -p /volume1/tools/nas-backup
curl -fsSL https://github.com/eferm/nas-backup/archive/refs/heads/main.tar.gz \
  | tar -xz --strip-components=1 -C /volume1/tools/nas-backup
cd /volume1/tools/nas-backup

# Install the pinned versions of restic + autorestic. The script detects
# architecture (x86_64 / arm64 / arm), verifies SHA256 checksums, and
# installs to /usr/local/bin.
sudo ./install.sh

To update later: re-run the curl | tar command. Stash a copy of your .autorestic.yml edits first — the re-extract overwrites it.

Still in /volume1/tools/nas-backup:

# a. Create the secrets file and lock it down.
cp .autorestic.env.example .autorestic.env
chmod 600 .autorestic.env
vi .autorestic.env   # fill in RESTIC_PASSWORD and the B2 keys

# b. Edit .autorestic.yml:
#    - locations.nas.from   → the shares you actually want backed up
#                             Quote any path containing spaces.
#    - backends.b2.path     → <your-bucket-name>:nas

# c. Validate config + reach the backend. This also initializes the B2 repo
#    on first run. Safe to re-run; it's a no-op once everything is set up.
#    Does NOT upload any data.
autorestic check

Autorestic auto-discovers .autorestic.yml and .autorestic.env in the current directory, so every example in this README assumes you're in /volume1/tools/nas-backup.

Once check succeeds, the setup is done.

Control Panel → Task Scheduler → Create → Scheduled Task → User-defined script.

All three tasks run as root (needed to read every file under /volume1) and cd into /volume1/tools/nas-backup first so autorestic picks up .autorestic.yml from CWD.

Schedule times use the NAS's local timezone (Control Panel → Regional Options → Time), not UTC. Set the timezone there first if it's wrong.

• General

  • Task: Restic Backup
  • User: root
  • Enabled: yes

• Schedule

  • Run on: Daily
  • First run: whatever time the NAS is usually idle (e.g. 03:00)

• Task Settings → Run command

  cd /volume1/tools/nas-backup && /usr/local/bin/autorestic --ci backup -a

• Task Settings → Notifications: tick "Send run details only when the script terminates abnormally" and point it at an email you read.

Pruning rewrites pack files on B2 and costs bandwidth/class-C transactions, so run it on a lower cadence than backups.

• General

  • Task: Restic Prune
  • User: root

• Schedule

  • Run on: Weekly, Sunday, 04:00 (after the nightly backup has finished)

• Task Settings → Run command

  cd /volume1/tools/nas-backup && /usr/local/bin/autorestic --ci forget -a --prune

Verifies pack file structure and re-reads a sample of data from B2.

• General

  • Task: Restic Check
  • User: root

• Schedule

  • Run on: Monthly, Last, 05:00

• Task Settings → Run command

  cd /volume1/tools/nas-backup && /usr/local/bin/autorestic --ci exec -b b2 -- check --read-data-subset=5%

The --ci flag suppresses autorestic's interactive progress UI, which otherwise clutters Task Scheduler's output log.

Backups, forgets, and integrity checks run only through Task Scheduler — do not kick them off ad hoc. The commands below are read-only or recovery operations and are safe to run by hand. cd into the repo first so autorestic picks up the config automatically.

# List snapshots
autorestic exec -b b2 -- snapshots

# Dry-run the retention policy — shows what forget would delete, deletes nothing
autorestic forget -a --dry-run

# Find a file across snapshots
autorestic exec -b b2 -- find path/to/file

# Restore a snapshot into /tmp for inspection
autorestic restore -l nas --from b2 --to /tmp/restore-check

# Unlock the repo if a scheduled job died mid-run and left a stale lock
autorestic exec -b b2 -- unlock

If you genuinely need an off-schedule backup (e.g. before a risky migration), trigger Task 1 manually from DSM: Task Scheduler → select the job → Run. That keeps every backup run attributable to the same code path, logs, and notification channel as the scheduled runs.

If the NAS is gone and all you have left is this repo and the RESTIC_PASSWORD

• B2 keys:

1. Install restic on any machine.

2. Export the env vars:

   export RESTIC_REPOSITORY="b2:<bucket>:nas"
   export RESTIC_PASSWORD="<the password>"
   export B2_ACCOUNT_ID="<keyID>"
   export B2_ACCOUNT_KEY="<applicationKey>"

3. restic snapshots to list, then restic restore <id> --target /some/path.

Autorestic is not required for restore — it's just a wrapper. The repo is pure restic.

Re-extract overwrites .autorestic.yml; .autorestic.env is gitignored so it's safe.

cd /volume1/tools/nas-backup
cp .autorestic.yml .autorestic.yml.bak
curl -fsSL https://github.com/eferm/nas-backup/archive/refs/heads/main.tar.gz \
  | tar -xz --strip-components=1 -C .
diff .autorestic.yml.bak .autorestic.yml

Manually resolve .autorestic.yml using the diff (your local edits will show up alongside any real upstream changes). Then rm .autorestic.yml.bak and, if install.sh bumped versions, sudo ./install.sh.

Pinned versions live at the top of install.sh. Restic's on-disk format is stable across versions, so there's no urgency — only bump when you actually want a fix or feature.

1. Check latest releases:
   • https://github.com/restic/restic/releases
   • https://github.com/cupcakearmy/autorestic/releases
2. Download the SHA256SUMS file from each release page and copy the three linux digests (amd64, arm64, arm) into install.sh.
3. Update RESTIC_VERSION / AUTORESTIC_VERSION.
4. Commit, pull on the NAS, sudo ./install.sh. The script verifies the checksums before touching /usr/local/bin.

• DSM rootfs is ~2GB. Keep the repo, restic cache, and any restore target on /volume1. AUTORESTIC_B2_RESTIC_CACHE_DIR in .autorestic.env handles the cache.
• @eaDir (Synology's thumbnail/index sidecar dirs) are already excluded.
• Backblaze lifecycle rules must be "Keep only the last version" or disabled — anything that hides/deletes files on B2's side will corrupt the restic repo.
• First backup is slow. Subsequent runs only upload changed chunks.
• Don't rotate the B2 key without updating .autorestic.env. Old keys stop working immediately; the scheduled task will just start failing silently unless you wired up the abnormal-termination notification above.