Reliable NAS Backup and Restore: ZFS, Borg, Restic, and a Real DR Plan

If you’re running a home server, a solid NAS backup and restore strategy is not optional — it’s what separates a recoverable incident from a catastrophic, unrecoverable data loss. Most homelab guides stop at RAID or ZFS mirrors and call it done. That’s not backup. This post walks through how to build a proper NAS backup and restore pipeline using ZFS snapshots, Borg, and Restic — and how to put together a disaster recovery (DR) plan you can actually execute under pressure.

---

RAID Is Not a Backup 🚫

Let’s clear this up immediately. RAID protects against drive failure — nothing else. If you accidentally rm -rf the wrong directory, your RAID mirror deletes it on every drive simultaneously. If ransomware encrypts your data, RAID helpfully syncs the encrypted version everywhere. If a software bug corrupts your filesystem, RAID propagates the corruption in real time.

A drive failure is actually one of the less likely data loss scenarios. Accidental deletion, software bugs, and human error are far more common — and RAID does nothing to protect you from any of them.

---

NAS Backup and Restore: The 3-2-1 Rule 📦

A robust NAS backup and restore strategy is built on the 3-2-1 rule:

• 3 copies of your data
• 2 different storage media
• 1 offsite (or off-device) location

The three tools covered in this guide map directly to these three layers. ZFS snapshots handle near-instant local recovery. Borg provides a deduplicated, encrypted local archive. Restic pushes a copy offsite or to the cloud. Together, they cover all realistic failure scenarios.

---

Layer 1 — ZFS Snapshots: Fast and Atomic ⚡

ZFS snapshots are the fastest form of NAS backup and restore available on Linux. A snapshot is a read-only, point-in-time copy of a dataset — it costs nearly zero storage to create initially and can roll back an entire dataset in seconds.

Creating a Snapshot

zfs snapshot pool/dataset@2025-01-15-daily

Listing Snapshots

zfs list -t snapshot

Rolling Back

zfs rollback pool/dataset@2025-01-15-daily

⚠️ Critical: zfs rollback permanently discards all changes made after the snapshot. There is no undo. Always double-check the snapshot name before running this command.

Automating Snapshots with Sanoid

For production-quality automation, use Sanoid. It manages snapshot creation and retention via a simple declarative config at /etc/sanoid/sanoid.conf and handles hourly, daily, and monthly snapshots automatically.

apt install sanoid

Sanoid is the backbone of a proper NAS backup and restore automation layer — set it up once, and forget it until you need it.

Replicating Snapshots with zfs send

ZFS snapshots can be shipped to a remote host over SSH:

zfs send pool/dataset@snapshot | ssh user@remote zfs receive remote-pool/dataset

Incremental sends only transfer changed blocks, making this an extremely efficient NAS backup and restore mechanism for off-device replication. If you’re already running ZFS on Proxmox, check out how to set up OneDrive sync to a ZFS mirror pool — it pairs naturally with snapshot-based backup.

---

Layer 2 — Borg Backup: Deduplicated and Encrypted 🔐

Borg is a deduplicating backup tool built precisely for the NAS backup and restore use case. It compresses and encrypts archives incrementally, so backing up 500 GB of media where 2 GB changed overnight takes seconds and stores only the delta.

Install Borg

apt install borgbackup

Initialize a Repository

borg init --encryption=repokey /mnt/backup/borg-repo

⚠️ Critical: Copy your repository key somewhere safe and off-device the moment you create the repo. Without the key, Borg archives are completely unrecoverable — by design.

Create a Backup Archive

borg create --stats --progress \
  /mnt/backup/borg-repo::'{hostname}-{now}' \
  /mnt/data

Restore from Borg

borg extract /mnt/backup/borg-repo::archive-name

Automating Borg with a systemd timer or cron job gives you a scheduled NAS backup and restore layer that runs quietly in the background. It integrates cleanly with OpenMediaVault’s shared folder structure — if you want to make sure your OMV drives are healthy enough to host your Borg repository, see how to test SSD and HDD speed on OpenMediaVault. Also worth checking: if your backup target drives tend to spin down, review how to disable disk spindown on OMV — a sleeping drive that doesn’t wake up fast enough can silently break your backup job.

---

Layer 3 — Restic: Cloud-Ready and Portable ☁️

Restic takes a different approach. It’s backend-agnostic and supports local paths, SFTP, S3, Backblaze B2, Azure, and Google Cloud Storage out of the box — making it the best option for the offsite leg of your NAS backup and restore plan.

Install Restic

apt install restic

Initialize a Local Repository

restic init --repo /mnt/offsite/restic-repo

Back Up a Directory

restic -r /mnt/offsite/restic-repo backup /mnt/data

Restore Latest Snapshot

restic -r /mnt/offsite/restic-repo restore latest --target /mnt/restore

Using Backblaze B2 or S3 as a Backend

export AWS_ACCESS_KEY_ID=your-key
export AWS_SECRET_ACCESS_KEY=your-secret
restic -r s3:s3.amazonaws.com/your-bucket backup /mnt/data

Restic snapshots are immutable and independently readable — a major advantage when your NAS backup and restore process needs to survive the total loss of the primary server. For managing Restic credentials in a Docker environment, the approach described in hardened Docker images for self-hosting applies directly — never hardcode passwords in shell scripts.

---

Borg vs Restic: Which One to Use? 🤔

Both tools are excellent choices for NAS backup and restore, but they shine in different scenarios.

• Borg has a longer track record, lower runtime overhead, and is better suited for on-site or LAN/SSH-based backups. It’s the natural fit for backing up to an attached drive or a second NAS on the same network.
• Restic wins on backend flexibility. If you need cloud storage, multi-machine access, or want to avoid a dependency on SSH, Restic is the better choice. Its CLI is also simpler to script.

The practical answer: use both. Borg covers Layer 2 (local archive), Restic covers Layer 3 (offsite). They don’t conflict and together they give you full 3-2-1 coverage.

---

Building Your DR Plan 📋

A NAS backup and restore plan only works if you can execute it calmly when everything is broken. Write this down before you need it:

Scenario A — Accidental file deletion → zfs rollback or borg extract from the nearest recent archive.

Scenario B — Dataset or filesystem corruption → Roll back to the last clean ZFS snapshot. If the snapshot is gone or tainted, restore from Borg.

Scenario C — Full NAS hardware failure → Provision new hardware → restore from Restic offsite repo → verify file checksums with restic check.

Scenario D — Ransomware or full compromise → Do not mount the affected drives on clean hardware immediately. Inspect the incident timeline offline first. Restore from a Restic snapshot that predates the infection.

---

Recovery Checklist ✅

Run through this checklist monthly to confirm your NAS backup and restore setup actually works before you need it:

1. 🔍 List all available snapshots: zfs list -t snapshot, borg list <repo>, restic snapshots
2. 🧪 Test-restore a file to a staging path — don’t just trust that backups exist; verify they’re readable
3. 🔑 Confirm your Borg key and Restic password are stored off-device (password manager, printed copy in a safe)
4. 📅 Review systemd or cron logs weekly — silent job failures are the leading cause of backup gaps
5. 🌐 Confirm the Restic offsite repository is reachable and the latest snapshot is recent
6. 📄 Keep a printed or USB-stored recovery command sheet — when the server is down, you may not have internet access to look things up

---

FAQ ❓

Q: Are ZFS snapshots enough on their own? No. Snapshots live on the same pool as your data. A drive failure, pool-level corruption, or ransomware can destroy both simultaneously. Snapshots are Layer 1 — always pair them with Borg and Restic.

Q: Does Borg work on OpenMediaVault? Yes. OMV is Debian under the hood. Install borgbackup via apt and schedule it with a systemd timer or cron. It integrates cleanly with OMV shared folders.

Q: How much disk space do Borg and Restic repositories need? Deduplication and compression typically reduce storage to 20–40% of raw data size for mixed homelab content (documents, configs, media). Large media libraries with unique files deduplicate less aggressively.

Q: How do I keep my offsite Restic backup secure? Use --password-file or the RESTIC_PASSWORD environment variable. Store credentials in a password manager. If you’re already self-hosting Bitwarden for secrets, your self-hosted Bitwarden instance is a perfectly reasonable place to store Restic and Borg credentials.

---

Conclusion 🎯

A production-grade NAS backup and restore strategy doesn’t require expensive hardware or enterprise software — it requires three overlapping layers and the discipline to test them. ZFS gives you instant, atomic local rollback. Borg gives you a deduplicated, encrypted local archive. Restic gets a copy offsite where a hardware failure or ransomware attack can’t touch it. Pair all three with a written DR plan and a monthly recovery test, and you’ll be the person who recovers their homelab in an afternoon instead of losing everything. Start with ZFS snapshots today. Add Borg this week. Point Restic at cloud storage this weekend. Future-you will be very glad you did.