Resilience architecture
Synology 3-2-1 Backup: Design Copies That Fail Independently
A Synology NAS can be the center of a strong 3-2-1 strategy, but the formula is useful only when the copies fail independently. Keeping production data, a backup repository and snapshots on the same DiskStation does not create three meaningful copies if one chassis, account compromise or building disaster can remove all of them. The design should deliberately separate location, media or system, credentials and recovery speed.
Quick answer
Three copies should not share one failure domain
Keep the working data on the Synology, maintain another recoverable copy on separate local storage or another NAS, and keep at least one copy offsite through a remote NAS or cloud target. Use snapshots for fast rollback, but do not count a snapshot on the same storage pool as the independent offsite copy. Test each recovery path.
Live Amazon products
Current hardware for this workflow
This Sprint 9E catalogue is intentionally small: it surfaces current and previous Synology systems relevant to photo, backup and remote-access ownership decisions, while compatible third-party NAS drives can be read from Cloudzat Storage Price Intelligence in read-only mode. Hardware cards support the workflow; they do not replace the application and recovery guidance on each page.
Owner decision
Design for the disasters you can name
Accidental deletion, failed disks, ransomware, NAS theft, fire and administrator mistakes are different threats. Map each threat to at least one copy that survives it. If every answer points to the same DSM administrator account or same room, the 3-2-1 diagram is decorative rather than resilient.
Interactive owner tool
Synology 3-2-1 Backup Planner
Use this as a planning aid. It identifies missing reliability layers and the simplest likely direction, but it does not replace current Synology, Immich, Backblaze, Google or Tailscale documentation for the exact service and software version.
Owner reliability checklist
Four checks before trusting the new workflow
Protect the original data
A photo or backup application is not the final safety layer. Know where originals live and keep an independent copy outside the primary NAS.
Design remote access by user role
Family photo access, private administrator access and public sharing do not need the same exposure or credentials.
Document recovery secrets
Encryption keys, cloud credentials, tailnet access and DSM accounts should remain recoverable even when the original NAS is unavailable.
Test before deleting the old copy
Migration and backup jobs are complete only after representative files restore, metadata looks correct and the next administrator can follow the procedure.
Count the production data as copy one
The active folders on the Synology are the first copy. RAID or SHR can keep that copy available through certain disk failures, but redundancy inside the array does not create another independently recoverable dataset.
That distinction matters because users often count mirrored disks as multiple copies. They are components of one storage system that shares the same chassis, filesystem and administrator controls.
Make copy two physically or logically separate
The second copy can live on an external drive, another NAS or another independent storage system. It should be recoverable without depending on the same disks that hold production data.
For fast local recovery, a USB disk or second NAS can be valuable because terabytes can move over local interfaces much faster than most Internet connections. Disconnecting or isolating local backup storage can also reduce ransomware exposure.
Put copy three somewhere the local disaster cannot reach
An offsite Synology, Synology C2, Backblaze B2 through S3-compatible Hyper Backup or another supported cloud target can provide geographic separation.
The goal is survival if the building, primary Internet gateway, UPS and NAS are all unavailable. “Offsite” should therefore mean a genuinely different location or provider failure domain, not a second drive sitting on the same shelf.
Use snapshots for speed, but classify them correctly
Snapshots can provide extremely fast recovery from accidental deletion or unwanted changes, especially on Btrfs volumes. They are an excellent resilience layer because rollback can be much faster than restoring a large Hyper Backup repository.
A snapshot stored on the same NAS still depends on that NAS. Count it as a recovery mechanism, not as the independent offsite copy required to survive total device loss.
Separate credentials when possible
If one compromised DSM administrator account can delete production files, local snapshots and every connected backup, physical separation alone may not be enough. Use distinct credentials and provider accounts where the design allows it.
Protect cloud accounts with strong authentication and avoid storing every recovery secret only on the production NAS. Administrative independence is an important but often ignored part of failure-domain separation.
Choose backup frequency from acceptable data loss
A photographer importing a wedding shoot may need an offsite copy the same day, while an archival media folder might change once a month. One universal schedule wastes resources or leaves critical data exposed.
Define recovery-point objectives by dataset. Use frequent snapshots for rapidly changing folders, nightly or hourly backup where needed, and less frequent jobs for large replaceable data.
Retention protects against late discovery
If ransomware or accidental edits are noticed days later, a backup containing only yesterday’s state may already include the damage. Versioned Hyper Backup repositories can preserve older states when retention is configured appropriately.
Use denser recent versions and longer-spaced older recovery points. The exact pattern should reflect how long users typically take to notice mistakes.
Capacity planning must include version history
A 10TB source does not automatically require exactly 10TB of backup storage. Deduplication and incremental changes can reduce growth, while version history, database churn and large edited files can increase it.
Monitor real backup-repository growth and leave free-space headroom. A nearly full destination can fail at precisely the time source data is expanding fastest.
Restore speed changes the value of each copy
Cloud storage is excellent for disaster survival, but downloading many terabytes can take days. A local copy may be more useful for common failures even if it is not the copy that protects against fire.
Document which copy is intended for which recovery. Staff should know when to restore from snapshots, when to use local Hyper Backup and when the offsite repository is the last-resort path.
Test the recovery chain end to end
Restore a file from snapshot, restore a folder from the local backup and retrieve a sample from the offsite repository. Those tests expose authentication, encryption and documentation problems before an emergency.
For important systems, simulate the loss of the original NAS credentials or hardware. A backup that can only be restored because the original NAS remembers every secret is not sufficiently independent.
Protect the backup configuration itself
Record task names, destination accounts, encryption keys, retention choices and important exclusions. Store that recovery information somewhere accessible even when the NAS is offline.
A future administrator should be able to identify the offsite bucket or remote NAS and know which repository contains the critical folders without reverse-engineering years of settings.
Revisit the architecture as storage grows
The 3-2-1 design that worked for 2TB may become slow or expensive at 30TB. Larger datasets can justify a second NAS, different cloud tier, selective offsite protection or faster network links.
Review the plan annually and after major changes in photo, video or business data. The principle stays constant while the practical media, bandwidth and budget choices evolve. Capacity growth can also change which copy is practical for daily recovery. A small external disk may be perfect when the NAS contains 2TB, then become a fragile manual process at 20TB. Revisit transfer time, automation, physical handling and the size of the restore window whenever the main storage pool expands. Resilience should scale with the dataset instead of freezing around the hardware purchased years earlier.
Questions people ask
Synology 3-2-1 backup questions
What does 3-2-1 backup mean?
It generally means three copies of data, on two types of media or systems, with one copy kept offsite. The copies should fail independently.
Does RAID count as a second backup copy?
No. RAID is redundancy within one storage system and does not protect against many file-system, administrator or site-level failures.
Do Synology snapshots count as backup?
Snapshots are valuable recovery points, but snapshots on the same NAS should not be counted as the independent offsite copy.
Can Hyper Backup provide the offsite copy?
Yes. Hyper Backup supports remote Synology systems and several cloud or S3-compatible destinations that can provide geographic separation.
Should I use an external USB drive?
It can be an excellent fast local recovery copy, especially if it is disconnected or otherwise protected from the production system when not in use.
How often should the offsite backup run?
Base frequency on how much new data you can tolerate losing. Critical working folders may need frequent jobs; archives may need less.
How much backup capacity do I need?
More than the current source size may be required once version history and future growth are included. Monitor actual repository growth.
What is the fastest recovery layer?
Local snapshots are often fastest for accidental deletion, followed by local backup storage. Offsite cloud is usually the disaster-survival layer rather than the fastest restore.
How do I protect against ransomware?
Use version history, separated credentials, isolated or disconnected local copies and an offsite copy that the compromised production account cannot easily destroy.
How often should I test restores?
Test regularly and after material configuration changes. Important business data deserves a documented recovery exercise rather than occasional spot checks.
Official references and methodology
Verify the exact service, data path and recovery plan
This page follows Synology’s own current 3-2-1 recommendation while emphasizing failure-domain independence. RAID, snapshots, local backups and offsite Hyper Backup are classified by the threats they survive, and the guide does not count multiple disks inside one NAS as multiple independent copies.
- Synology 3-2-1 guidance for Active Backup data
- Hyper Backup DSM 7.4 specifications
- Hyper Backup backup tasks
- Backblaze B2 Hyper Backup integration
As an Amazon Associate, Cloudzat may earn from qualifying purchases. Prices, NAS models, DSM behavior, application versions and service documentation can change. Verify the exact Synology model and the current Synology, Immich, Backblaze, Google or Tailscale documentation before changing a production photo, backup or remote-access workflow.