RAID vs snapshots vs backups: a recovery plan for a small NAS

Give your NAS an undo button—and a way back when the whole box is gone. RAID keeps you running through a drive failure your layout can tolerate. Snapshots keep earlier versions on surviving storage. A separate backup gets your files back after you lose the source; protect it from the credentials that can erase the original.

Recovery advice follows TrueNAS, restic and CISA; drive specifications come from the makers.

Buying the disks for that plan? Our NAS hard-drive buying guide compares WD, Seagate and Toshiba CMR models for a mirror or four-bay array. Keep an independent backup in the budget before filling every bay.

For the disk you disconnect after a backup, our USB SATA dock guide compares ordinary backup docks, documented SMART support and standalone cloners.

For a USB-connected destination, our TR-004 vs D4-320 DAS comparison separates enclosure RAID from individual disks and includes a backup-and-restore acceptance checklist.

For the files you cannot recreate, our Blu-ray offline archive guide shows how to choose a writer and media, make a checksum manifest and test the restored copy.

Start with the failure you need to survive

Write down what must come back and what can be rebuilt. Separate irreplaceable files from replaceable downloads, application state, configuration and recovery credentials. The list should identify each required source and any deliberate exclusion. “Back up the NAS” is too vague if the eventual restore needs data that never entered the job. For the power-cut part of the plan, compare NAS-friendly UPS models and shutdown connections.

Then define acceptable data loss and time to useful recovery. Use those targets to set retention and plan the restore drill. Decide how far back an unnoticed deletion must remain recoverable, and whether an interrupted service can wait while files are restored. Those answers determine retention and whether storage redundancy is worth adding for availability.

If the immediate choice is more redundancy or the first independent copy of unique data, ask which failure currently has no recovery path. An array that stays online after a disk fault does not supply the missing copy. The TrueNAS ZFS primer explicitly distinguishes disk redundancy from a backup strategy.

Choose recovery layers with the decision table

Pick the layer for the failure you need to survive.

Reader need	Choose this layer	Condition that still matters
Continue through a drive failure	A redundant storage layout	Failure remains within that layout’s tolerance
Recover a deleted or overwritten file	Retained local snapshots	A pre-event restore point and healthy source pool remain
Recover after losing the NAS or pool	A separate backup or replicated copy	The copy and recovery credentials survive independently
Survive deletion through compromised administration	Offline or appropriately protected retained copies	The attacker cannot delete every recovery copy
Recover a working application	Application-appropriate exports and a restore drill	Files, configuration and required secrets work together

This framework follows the storage boundaries in the TrueNAS primer and the backup-isolation advice in CISA’s ransomware guide. Redundancy does not provide file history by itself. A local snapshot depends on surviving source storage. An independent copy still needs working credentials, a suitable restore point and a usable recovery procedure.

Understand what local snapshots retain

The TrueNAS primer describes ZFS snapshots as point-in-time views, with old file blocks retained while snapshots reference them. Changes can therefore keep storage occupied even after a file disappears from the current view. Do not budget snapshot history as permanently free space, or assume deleting a current file immediately releases every referenced block.

Local snapshots are useful for a mistake discovered while the pool remains healthy. They are not another physical device. For source-storage loss, consider replication to a separate ZFS pool or a file backup with a separate destination. A replicated snapshot can be part of a backup design; the relevant question is where its data and recovery dependencies survive.

Do not choose snapshot retention solely by how many entries look tidy in a management screen. It must cover the mistakes you might discover late. Check how each task expires history at the destination, and whether the credentials used by the source can also remove it. A second copy with independently retained history has a different recovery boundary from a continuously updated mirror of current files.

Pick a destination by its failure boundary

Restic’s repository documentation supports local and remote repository locations. Choose a destination you can keep updated, with the failure separation you need:

Destination	Choose it when	Check before relying on it
Detached backup drive	Manual connection and rotation are sustainable	Update gaps, disconnected storage and separate recovery access
Separate backup NAS	Automatic transfers and independent hardware are useful	Shared credentials, location and deletion authority
Remote repository	A copy outside the source failure area is required	Account recovery, transfer demands and tested retrieval

A detached drive is offline only while it is disconnected. Include its update window in the threat assessment, and make missed updates visible. Store it separately if the backup must survive the same physical incident.

A separate NAS supplies separate hardware, but check what remains shared: administrative access, deletion rights and the physical incident being considered. Document which of those dependencies you have separated. A remote repository similarly needs an account-recovery route and a retrieval test; remoteness does not remove the consequences of compromised credentials.

Offline, offsite, encrypted and immutable describe different properties. Encryption is not deletion protection. CISA recommends offline encrypted backups and regular recovery testing because ransomware can target accessible backups. For protected retention or immutability, read the backend’s retention rules, maintenance permissions and costs.

If the storage plan needs more internal connections, the SATA and HBA buying guide compares cards and cable requirements. Extra ports can connect the drives; they do not create an independent backup boundary.

HDD or SSD: which one for which backup job?

Choose the drive for the copy you need to carry away. For a large file collection, the WD Red Plus 8 TB (WD80EFPX) gives you a roomy bare SATA disk to use with a powered dock. For Home Assistant exports, VM archives and a drive you take between computers, choose the Samsung T7 Shield 2 TB. Already have a healthy drive with enough space? Put it through the restore drill below before shopping. For SSDs inside the NAS, use our NVMe cache and app-pool guide to choose their job.

Your backup job	Choose	Why it fits	Make it work
A large NAS file collection, copied at a desk	WD Red Plus 8 TB plus a powered SATA dock	8 TB of nominal capacity for files and retained history	Add a compatible 3.5-inch dock; the bare drive has no USB port
Home Assistant exports and a portable VM archive rotation	Samsung T7 Shield 2 TB	An enclosed 98 g drive with a 10 Gbps USB connection	Use a data cable and a host that can read your backup format
A smaller file set that fits a spare external drive	Keep the working HDD or SSD	A successful restore matters more than a new enclosure	Check its health, free space and recovery access
Automatic nightly copies with little manual handling	A separate network backup destination	It stays available for scheduled jobs	Keep another protected or disconnected copy for source compromise

HDD: bulk files and a place on the desk

The WD Red Plus datasheet lists the WD80EFPX as an 8 TB, CMR, 3.5-inch SATA drive with a three-year limited warranty. Pair it with a powered dock, run your backup, eject it and store it in a protective case. Keep the dock on a stable surface while the disk is running.

Our USB SATA dock guide helps you choose the connection: StarTech for documented SMART support, Sabrent’s dual-bay option for standalone cloning, or a compact single-bay dock for ordinary file backups. For this job, use backup software to copy the NAS files; cloning one RAID member doesn’t back up the whole array.

SSD: the grab-and-go recovery copy

The T7 Shield datasheet lists USB 3.2 Gen 2 at 10 Gbps, 98 g and a three-year limited warranty. The 2 TB version suits a portable recovery set that fits its capacity, without a separate dock and power brick to carry.

Use our external SSD backup guide for the actual Home Assistant download, Proxmox archive and encryption-key steps. Keep the recovery key somewhere you can reach without the failed host. Buying an encrypted drive is only useful if your recovery machine can unlock it.

Size the backup, then give it room to grow

Start with a completed backup and its retained history, rather than the total size printed on your NAS disks. Leave room for the next run before pruning older copies. Pick the HDD when the portable SSD cannot hold the recovery set you need; pick the SSD when carrying a compact, self-contained drive makes your rotation easier to keep.

Finish the job: restore something useful, safely eject the drive, then disconnect it. CISA recommends offline, encrypted backups and regular recovery testing. A drive left plugged into the compromised machine can be another target.

Include application data and the restore dependencies

For ordinary files, decide which content and metadata the restored workload needs. For application state, follow the application’s documented export or quiesce procedure. Do not assume that copying a visible directory is sufficient to recreate a working database or service. Include required configuration and identify how necessary secrets will be recovered without putting them in public logs.

Treat export production and backup storage as separate steps with separate failure signals. The restic backup documentation warns that it cannot determine whether arbitrary standard-input data is complete. A failed export piped into a backup can otherwise leave an unusable result that looks reassuring.

The documented --stdin-from-command route checks the producer’s exit status and cancels the backup when that command fails. Then validate the export by importing or opening it in your restore environment and performing a useful operation.

For virtualised application data, the Proxmox versus direct Docker guide explains why host, guest and application backup coverage must be traced separately. A file-backup tool should not be assumed to recreate the NAS storage configuration or every guest dependency automatically.

Make failed and missing backups visible

Restic documents backup exit status 0 for a successful snapshot with all source files, 1 for a fatal error without a snapshot, and 3 when unreadable source files leave an incomplete snapshot. Investigate status 3 before treating that snapshot as a complete copy.

Record the job result, source-file errors and the intended scope. Investigate exclusions and unreadable paths instead of reporting success because a destination gained data. A successfully captured export still needs the application-level check described above. Keep job completion, repository integrity and successful application recovery as separate observations.

Choose monitoring that can reveal an absent job as well as a failed one. A recovery requirement is not met by an old successful status that nobody notices has stopped advancing. Define who checks exceptions and what evidence is retained, without assuming a notification mechanism will repair the underlying failure.

Set retention and protect recovery access

Keep enough history for the discovery window you actually need, then measure growth under representative changes before sizing the destination. Retained snapshots and repositories need capacity monitoring. Choose retention and destination capacity from that measured growth.

Specify who can delete historical copies, including maintenance credentials. Ask whether a compromised source can erase the destination or shorten its retention. Push and pull arrangements should be evaluated through those permissions rather than treated as automatically safe categories. Test the supported access model before describing a target as deletion-resistant.

Recovery keys are another dependency. Restic repositories require usable password/key access and can support multiple keys. Its documentation warns about losing access when a password is lost. Preserve a working recovery route and instructions independently from the NAS being recovered; another usable key matters more than a remembered label saying “encrypted backup.” Test that route without publishing credentials or relying on the unavailable source machine.

Separate repository checks from restore tests

The repository-check documentation distinguishes structural checks from reading stored pack-file data. Default restic check does not read and verify every pack file’s contents. restic check --read-data adds that data check; it can take more time and transfer more data. A subset check covers its selected subset, not every stored byte.

After checking the repository, restore the export and configuration, recover without the source NAS, and run an application operation. Save each result.

Plan retrieval as part of the design. You need a suitable target with space for the restore and access to the required software and credentials. Do not discover those dependencies only after the source has failed. Record transfer and restore observations when tested rather than advertising a recovery duration based on a connection’s nominal rate.

Take your backup for a test drive

Use expendable test data and a fresh, separate restore target. The restore documentation notes that existing target files are overwritten by default. An initial drill should not risk the only good working copy.

Record the tool version, source scope, exclusions, job status and chosen restore point. Select a historical point appropriate to the simulated mistake, rather than automatically taking the newest entry.
Start with the source treated as unavailable. Confirm that the recovery instructions, repository access and a working key can be obtained independently.
Inspect the selected contents, then restore into the separate target. In restic, --path selects a snapshot; it does not restrict the restored contents to that path. Check the documented selection and filtering semantics before running the restore.
Open representative files and compare known content. Check the ownership, permissions or other metadata the workload requires. Record the files and metadata you checked.
Restore the application export or state using its documented procedure, then perform a useful operation. A directory of files is not the same observation as a working application.
Record elapsed observations, missing dependencies and unresolved failures. Expand from selected files to a full-system drill when that is your recovery target.

Preserve the original and investigate failures before deleting history or changing the source.

For container applications, use the Docker Compose backup guide to inventory persistent state, choose a consistency method and verify separate restore targets before testing the application.

Running out of room for apps rather than files? The NAS RAM upgrade guide helps you read memory pressure and choose a model-compatible module.

Choose a practical starting plan

For mostly irreplaceable files and tolerable downtime, prioritise an independent, recoverable copy and a manageable restore drill. Add local snapshots for convenient historical recovery, and redundancy when continued operation through a tolerated disk fault is required.

For application-heavy storage, add successful application exports, configuration and credential recovery to the same plan. For a design that must survive source administration being compromised, include a copy whose retained history those credentials cannot erase, and verify the specific protection rather than assuming it from the destination’s name.

The completed plan should say what is protected, which failures it addresses, where surviving history comes from and what a restore test has actually shown. Put the next restore drill on your maintenance list.

For a networked backup path, the small-lab switch and NIC buying guide compares 2.5GbE options and counts the connections left after an uplink. Buy the whole transfer path only when the network is the bottleneck; a faster link does not replace a recoverable backup.

Once the recovery layers are defined, the ZFS, mdadm and hardware RAID decision guide compares who owns the storage layout and filesystem, what maintenance each stack needs and how replacement recovery would be verified.

A separate system-drive purchase is a different decision from backup capacity. The NVMe boot-drive comparison helps you choose a boot drive while keeping the independent backup in the plan.

For the enclosure choice, our DXP2800 vs DS225+ buying comparison shows what a two-drive mirror means for capacity, how the backup tools differ and when four bays fit better.

For a compact removable copy of your Home Assistant exports or VM archives, our external backup SSD guide compares two drives and walks through encryption and a restore drill.