NAS Backup Strategy: The 3-2-1 Plan That Restores

A NAS is not a backup. It is usually the place where your primary data lives, and even a redundant pool is still one location with one power source, one administrator, and one failure boundary.

A useful NAS backup strategy gives you three copies, two kinds of storage or failure boundary, and one copy somewhere else. It also gives you a way to restore a file, a service, or the whole system without guessing which password, key, or configuration was forgotten.

This guide builds that plan around a NAS first. For software-specific commands for Docker and Proxmox, see our mini PC home server backup guide. For primary pool sizing, use the NAS capacity planning guide and the NAS capacity calculator.

The 3-2-1 plan in a NAS

CISA describes the pattern as three copies of important data, two different media types, and one copy stored offsite. The point is not to memorize the numbers. The point is to avoid one incident removing every copy at once.

For a small home NAS, the map can look like this:

The local copy should not be a second dataset on the same pool. A snapshot is useful for quick rollback, but it is not an independent copy. A mirror is useful for availability, but it is not an offsite copy. A second NAS in the same room improves convenience more than disaster recovery.

The offsite copy should not be mounted with unrestricted write access from every machine. If ransomware can delete the primary data and the local backup with the same credentials, it may also delete the offsite copy. Separate accounts, delayed deletion, object lock, offline rotation, or a remote host with restricted access close that gap.

Decide what is worth restoring

Not every byte deserves the same backup schedule or destination. Separate irreplaceable data from rebuildable data before choosing a tool.

Back up first

• Family photos and videos
• Documents and project files
• Password-manager data and encryption keys
• NAS configuration exports
• Databases and application state
• Container volumes and compose files
• Virtual-machine disks that would be costly to rebuild

Rebuild or re-download when appropriate

• Container images
• Operating-system installation media
• Cached thumbnails that can be regenerated
• Temporary downloads
• Media that has a lawful, reliable replacement source
• Build artifacts that can be recreated from source

Rebuildable does not mean unimportant. Write down how to rebuild it. A configuration file and a list of image versions can turn a weekend recovery into an afternoon recovery.

The most commonly missed backup is the application database. The media files may still exist while the index, tags, user accounts, or document metadata disappear. Back up the data that makes the service useful, not only the large folders that are easy to see.

Four layers of protection

The strongest home NAS plans use several layers, each with a different recovery speed.

Snapshots for fast rollback

ZFS snapshots are excellent for recovering a file deleted recently or rolling back a bad change. They are space-efficient because unchanged blocks are shared until data changes. They still live in the same pool, so a pool failure, theft, or ransomware event can remove them along with the primary data.

Keep snapshots short and purposeful. A few hourly snapshots, daily snapshots for a week, and weekly snapshots for a month may be useful for active documents. Long retention can consume more space than expected when files change frequently.

Local backup for practical recovery

A local USB disk or second NAS is the fastest independent copy to restore from. It can handle a failed pool, an accidental dataset deletion, a bad configuration change, or a replacement NAS while the offsite copy remains available for larger disasters.

The local target needs enough capacity for the retention policy, not only one current copy. If it is permanently connected and writable, it is still exposed to mistakes and ransomware. Consider keeping one disk disconnected or rotating two local disks so the newest backup cannot destroy the older one.

Offsite backup for disaster recovery

Offsite storage is what protects against events that affect the entire room. A cloud object-storage bucket is convenient, while a remote NAS or server can provide more control and potentially lower recurring storage cost when you already have the hardware.

The offsite target needs encryption, a separate credential, and a documented recovery path. If the backup tool encrypts data before upload, the provider does not need your files in readable form. The trade-off is that losing the repository password or key can make the backup unrecoverable.

Offline or immutable copy for hostile deletion

A 3-2-1 plan does not automatically resist an attacker with valid credentials. Add a delay between backup creation and deletion, use object lock where the provider supports it, or keep a rotated disk offline. Immutability is a separate property from redundancy.

Restic or Borg?

Both tools create versioned, deduplicated backups and can encrypt data before it leaves the source. They are not interchangeable in every deployment because their destination models and operating habits differ.

Restic’s documentation provides a simple flow: initialize a repository, create snapshots, list snapshots, restore a snapshot, and periodically run a repository check. It also separates forgetting snapshots from pruning unreferenced data, which matters when retention is automated.

Borg’s documentation emphasizes content-defined chunks, client-side encryption, compression, and remote repositories over SSH. That makes it attractive when a second mini PC, a rented server, or a trusted remote machine is available.

Neither tool is a backup plan by itself. The schedule, target separation, key storage, retention, spending limit, and restore test matter more than the command name.

A simple Restic layout

Restic works well when the NAS sends encrypted snapshots to a local disk and an object-storage target. Use separate repositories for separate failure boundaries when that makes access control clearer.

The first-time flow is conceptually:

export RESTIC_REPOSITORY="s3:https://object-storage.example/bucket"
export RESTIC_PASSWORD_FILE="/path/to/restic-password"

restic init
restic backup /path/to/important-data
restic snapshots
restic restore latest --target /path/to/restore-test
restic check

Keep credentials outside the command history and outside the data being backed up. Use a password file with restrictive permissions or a secret manager, and store a separate recovery copy of the repository password in a place that is not dependent on the NAS.

For retention, define the policy in plain language before translating it into forget options. For example:

• Keep the last seven daily snapshots
• Keep four weekly snapshots
• Keep twelve monthly snapshots
• Keep a yearly snapshot for important archives

Run pruning only after you have checked that the retention policy selects the snapshots you intend to keep. Restic documents that forget removes snapshot references and prune removes data no longer referenced. A mistake in retention can delete the only historical copy of a file, so test the policy on a disposable repository first.

Run restic check regularly. A metadata check is lighter, while restic check --read-data reads the stored data and can require substantial network transfer. Schedule the full check when the offsite provider’s retrieval and egress terms are understood.

A simple Borg layout

Borg is a good fit for a remote host where SSH access is available and the host can store a Borg repository. The remote machine should have its own account, storage monitoring, and a backup that protects the Borg repository itself if it is the only remote copy.

The workflow is conceptually:

export BORG_REPO="ssh://backup-user@remote-host/./nas-repository"
export BORG_PASSPHRASE_FILE="/path/to/borg-passphrase"

borg init --encryption=repokey-blake2
borg create --stats "$BORG_REPO"::'{hostname}-{now}' /path/to/important-data
borg list "$BORG_REPO"
borg extract "$BORG_REPO"::archive-name path/to/file
borg check "$BORG_REPO"

The exact encryption mode and SSH layout should follow the current Borg documentation. Protect the repository key and passphrase separately from the remote host. If the NAS is compromised, the attacker should not be able to replace the only copy of the key and delete every archive without another control.

Borg’s chunk-level deduplication can help when large files change in small regions, but do not promise a fixed space saving. A database, virtual disk, or encrypted archive may change in ways that reduce deduplication. Measure the stored repository after the first retention cycle.

What offsite actually costs

The cloud bill is not just the size of the NAS. It is the size of the retained backup after deduplication, plus the data you download during recovery, plus any transaction or retrieval charges.

Use this model:

monthly storage cost
= retained backup bytes × current storage rate
+ paid retrieval or egress
+ transaction charges
+ recovery staging storage

For a remote server, replace the storage rate with the host’s monthly storage fee and add transfer charges, maintenance, and the cost of keeping the remote machine powered. For a rotated disk, replace the monthly rate with the purchase cost, replacement schedule, transport, and the time required to connect and verify it.

The five numbers to estimate

1. Current protected data
2. New or changed data per month
3. Retention period and number of versions
4. Deduplicated stored size after the first full backup
5. Recovery data likely to be downloaded in a year

Suppose the NAS protects 4TB but only 200GB changes each month. A deduplicating backup may store much less than twelve full copies, but the result depends on file changes, encryption boundaries, compression, retention, and pruning. If the NAS protects VM images or databases, small logical changes may still create substantial backup chunks.

Do not size only for the steady-state bill. A first upload can take time and consume bandwidth, while a full disaster restore can download much more than a normal month. Backblaze B2’s current pricing page describes free uploads, a monthly storage rate, included egress up to a multiple of average stored data, and additional charges beyond that allowance. It also provides a calculator and transaction details. Use the live page before choosing a provider because rates and terms change.

Set provider spending caps and alerts before the first large upload. Backblaze documents that an account without caps can accumulate unlimited charges. A cap that is too low can interrupt a backup, but no cap is an avoidable billing risk.

Cloud or remote server?

Choose object storage when you want simple scaling, client-side encryption, and a destination that does not need a machine running at your house. Accept variable storage and recovery charges, provider account management, and the need to understand object retention controls.

Choose a remote server when you already control the destination, need SSH-based tools such as Borg, and can manage its disk health, access, updates, and second copy. A remote server is not automatically offsite protection if it shares your building or your credentials.

Choose rotated disks when the data set is modest, recovery speed matters, and you can keep at least one disk physically disconnected. Rotation creates manual work, but it makes the failure boundary easy to understand.

Retention that fits real data

Retention is a policy, not a pile of snapshots. Decide how far back you need to recover from these events:

Long retention is valuable only if you can find the right version. Name backup jobs by source and keep a short recovery runbook with the retention policy, encryption key location, and restore command.

Do not prune every target on the same schedule. A local backup can keep more recent versions for quick recovery, while the offsite target keeps fewer but older versions. For irreplaceable photos and documents, a yearly archive may be worth the storage cost even when daily application data is pruned aggressively.

Protect the backup from deletion

The main NAS account should not have unrestricted authority over every copy. Use separate identities and restrict each one to the required destination.

For an object-storage target:

• Use a bucket or container dedicated to backups
• Create an application key limited to that destination
• Do not reuse the NAS administrator password
• Enable object lock or retention where the provider supports it
• Set spending alerts and data caps
• Keep the repository password outside the NAS

For a remote Borg host:

• Use a dedicated SSH account
• Restrict the key to the backup command or repository path when practical
• Keep the remote host outside the local administrator account
• Monitor repository and filesystem capacity
• Protect the remote host from deletion by the same compromised credentials

For a local disk:

• Rotate at least two disks for important data
• Disconnect the older copy after verification
• Label the disk with its role and last verification date
• Store it somewhere protected from the same flood, theft, or fire

Encryption protects confidentiality. Immutability protects against deletion during a retention window. Neither protects against a lost passphrase, so the recovery key needs its own offline copy.

Restore tests are part of the backup

Backup logs prove that a process ran. They do not prove that the target is readable, the key works, the permissions are usable, or the restored application can start.

Use three test sizes:

Monthly file test

Restore a randomly selected document or photo to a temporary directory. Open it, compare its checksum when appropriate, and record the snapshot or archive used.

Quarterly service test

Restore one application database and its configuration to an isolated container or test host. Start the service without pointing it at the production data. Confirm logins, recent records, attachments, and scheduled jobs.

Twice-yearly disaster test

Start with a blank destination or replacement system. Restore the NAS configuration, encryption keys, datasets, and the most important services. Record the elapsed time, missing dependencies, and bandwidth bottlenecks.

Test the offsite copy separately from the local copy. A local restore can succeed while the offsite key, provider account, or object-retention policy is broken.

The restore runbook should answer:

• Where is the repository or archive?
• Which password or key opens it?
• How do you install the backup tool on a clean host?
• Which snapshot or archive should be restored first?
• Where do restored files land before production use?
• Which permissions and owners must be fixed?
• How do you know the service is healthy?

Who should skip each approach

Skip cloud object storage if you are unwilling to understand its storage, egress, retention, and key-management terms. A cloud bucket is not set-and-forget just because it is remote.

Skip a remote Borg host if you cannot keep that host patched, monitored, and protected by a second copy. SSH access alone does not make the destination reliable.

Skip a single permanently connected USB disk if ransomware or a power event is part of your threat model. Add rotation or another independent copy.

Skip long retention if you will never test or search it. A large archive that cannot be restored is expensive storage, not recovery.

Skip backing up only the media library if the NAS also runs databases, photos, documents, and containers. The service state is often harder to recreate than the large files.

A practical NAS backup checklist

1. List the data that must survive and the data that can be rebuilt.
2. Record the current protected size and monthly change rate.
3. Create a local backup target outside the primary pool.
4. Create an offsite target with separate credentials.
5. Choose Restic for encrypted local or object-storage snapshots, or Borg for an SSH-controlled remote host.
6. Write a retention policy before enabling pruning.
7. Protect the offsite copy with object retention, rotation, or delayed deletion.
8. Store the repository password and recovery key separately from the NAS.
9. Set provider spending caps and alerts.
10. Schedule file, service, and disaster restore tests.
11. Record the result of every restore test and fix the runbook while the system is healthy.

Final answer

The simplest useful NAS backup is not another dataset on the same pool. It is a separate local copy plus an offsite copy, each with a known retention policy and a tested restore path.

Use snapshots for quick rollback, a local target for fast recovery, and encrypted Restic or Borg backups for a separate failure boundary. Add immutability or offline rotation when deletion and ransomware matter. Calculate offsite cost from retained bytes and recovery traffic, not only the current size of the NAS.

The 3-2-1 rule is the floor. The real goal is a restore you can perform after the NAS, the room, or the administrator’s memory has failed.

---

Frequently Asked Questions

Is a NAS itself a backup?

No. A NAS is usually the primary copy or the destination for one backup. A backup needs another independent copy, and a 3-2-1 plan adds a second medium and an offsite location so one failure cannot remove every copy.

Is RAID a backup?

No. A mirror or RAIDZ pool helps a NAS stay available after some drive failures, but it does not protect against deletion, ransomware, fire, theft, or a mistake replicated to every disk.

Should I use Restic or Borg for a NAS backup?

Use Restic when encrypted file-level snapshots need to reach local storage or object storage with a simple client workflow. Use Borg when you control an SSH-accessible backup host and want chunked, encrypted archives there. Either tool still needs a restore test and protected keys.

How much does offsite NAS backup cost?

Calculate stored backup bytes multiplied by the provider’s current storage rate, then add any paid egress, transaction, retrieval, and recovery-staging costs. Deduplication reduces stored change, but retention and restore volume determine the real bill.

How often should I test a NAS backup?

Test a file restore monthly, a service restore at least quarterly, and a larger disaster-recovery exercise at least twice a year. A successful backup job proves that data was written, not that the application, permissions, encryption key, and recovery steps work.

---

Sources and further reading

• CISA data backup options
• Restic introduction and quickstart
• Restic retention and pruning
• Restic repository checks
• BorgBackup introduction
• Backblaze B2 cloud storage pricing
• Backblaze B2 data caps and alerts