Back up with restic

restic gives you what plain sync can't: every backup run is a browsable point-in-time snapshot, identical data is stored once (deduplication), and everything is encrypted on your machine before it leaves. Combined with CapyArk's own ZFS snapshots underneath, this is a seriously robust setup.

Why restic on CapyArk

• Client-side encryption, always on — file contents and names are opaque in storage. Zero-knowledge from CapyArk’s perspective.
• Deduplication — a hundred copies of the same file cost one. Repeated backups of mostly-unchanged data are tiny and fast.
• Your own version history — restore any past backup run, independent of (and in addition to) your plan’s ZFS snapshot retention.
• Works over plain SFTP — no server-side software needed, which fits CapyArk’s locked-down SSH perfectly.

Prerequisites

• Connected to your CapyArk network
• restic installed — restic version (packages: apt install restic, brew install restic, or restic.net)
• SSH key authentication set up (recommended for unattended runs — see Security best practices)

Step 1 — Initialize the repository

restic -r sftp:storage-baas_xxxxx:/restic init

You’ll be asked to choose a repository password.

This password encrypts everything and is unrecoverable. Not by you without it, not by CapyArk, not by anyone. Store it in a password manager and somewhere offline. Losing it means losing the backups.

Step 2 — First backup

export RESTIC_REPOSITORY=sftp:storage-baas_xxxxx:/restic
export RESTIC_PASSWORD_FILE=/root/.restic-password   # chmod 600!

restic backup /home /etc --verbose

Subsequent runs upload only new or changed blocks — a daily backup of a 100 GB dataset that barely changed transfers megabytes, not gigabytes.

Step 3 — Schedule and prune

/etc/systemd/system/capyark-restic.service:

[Unit]
Description=CapyArk restic backup

[Service]
Type=oneshot
Environment=RESTIC_REPOSITORY=sftp:storage-baas_xxxxx:/restic
Environment=RESTIC_PASSWORD_FILE=/root/.restic-password
ExecStart=/usr/bin/restic backup /home /etc
ExecStartPost=/usr/bin/restic forget --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --prune

/etc/systemd/system/capyark-restic.timer:

[Unit]
Description=Daily CapyArk restic backup

[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true

[Install]
WantedBy=timers.target

systemctl enable --now capyark-restic.timer

The forget --prune line is restic’s own retention policy: keep 14 daily, 8 weekly, 12 monthly versions, delete the rest. Tune to taste — deduplication makes generous retention cheap.

Restoring

# List backup runs (restic calls them snapshots)
restic snapshots

# Restore the latest state of one directory
restic restore latest --target /restore --include /home/you/documents

# Browse a backup interactively before restoring
restic mount /mnt/restic     # then browse /mnt/restic/snapshots/...

# Find which backup contains a file
restic find "invoice-2026*.pdf"

Maintenance

Run occasionally (monthly is plenty):

# Verify repository integrity
restic check

# Deeper check — re-reads a random 5% of actual data
restic check --read-data-subset=5%

Put restic check in a monthly timer and you have what most backup setups lack: automated proof the backups are restorable.

Troubleshooting

repository is already locked A previous run was interrupted. Confirm no restic process is running, then restic unlock.

First backup is slow Normal — everything is chunked, hashed, and encrypted once. Subsequent runs are dramatically faster. You can cap resource use with --limit-upload (KiB/s) if needed.

SSH command failed on init The /restic parent path is created automatically, but check the basics: tailscale status up, ssh storage-baas_xxxxx works, key added in Settings → SSH Keys.

How does this interact with CapyArk’s ZFS snapshots? Perfectly — they layer. ZFS snapshots capture the whole restic repository at points in time, so even a worst-case restic bug (or a forget you regret) can be rolled back via snapshot restore.