Synology Snapshot Replication: snapshots and retention

DSM 7.3 status (as of the October 2025 reversal + March 2026 Update 3)

• Snapshot Replication requires Btrfs volumes — confirm with Storage Manager > Storage > Volume detail > File system: Btrfs (the screenshot to the right shows this for Volume 2 on DSM 7.3). On 2024-and-older Plus models you can create Btrfs pools on either Synology-listed or third-party drives; non-listed drives just show 'Unverified' with a warning. On 2025-series Plus (DS725+, DS925+, DS1525+, DS1825+) DSM 7.3 lifted the install/pool-creation block, so Btrfs + Snapshot Replication now works with non-listed SATA drives — but M.2 NVMe cache for snapshot writeback is still HCL-locked, and dedup is still disabled on unverified drives.
• This page's procedure assumes DSM 7.3.2-86009 Update 3 or later. The Snapshot Replication package gets bundled updates with DSM major releases; if you're on DSM 7.2.x or earlier the per-share Schedule UI lays out differently and some retention modes (calendar-based retention) were added in 7.3.
• If you have Snapshot Replication tasks created on DSM 7.2.x running on 2024-or-older hardware and you migrate them to a 2025-series Plus, the tasks transfer cleanly — DSM 7.3's package version is forward-compatible with snapshots created under 7.2.x.

Snapshot vs backup (and why this matters)

• A snapshot is a Btrfs-level point-in-time reference to existing blocks on the volume. Creating a snapshot is near-instant and uses very little space initially; the snapshot only consumes capacity as the underlying blocks diverge from the snapshot.
• Snapshots protect against accidental delete, accidental overwrite, ransomware encrypting in place, and app data corruption. They do NOT protect against volume failure, drive-pool destruction, theft, fire, or someone deleting both the data and the snapshots (which an attacker with admin access can do).
• Snapshot Replication adds the missing piece: replicate snapshots to a second Synology NAS, off-box. Now a snapshot survives losing the primary NAS. This is still not equivalent to a real offsite encrypted backup, but it's a meaningful protection layer.
• Order the layers: Snapshot for instant recovery → Snapshot Replication for off-box snapshot survival → Hyper Backup for versioned encrypted backup with retention. Skipping any layer leaves a recovery scenario uncovered.

Setting up snapshots on a shared folder

• Verify the volume is Btrfs: Storage Manager > Storage > Volume > details. The File system field says btrfs. EXT4 volumes don't support Snapshot Replication; you'd need to migrate (Hyper Backup the data, recreate the volume as Btrfs, restore).
• Install Snapshot Replication from Package Center if not already installed.
• Open Snapshot Replication > Snapshots > select the shared folder > Settings > Schedule. Tick Enable snapshot schedule; pick a frequency (hourly for active-edit shares, daily for media libraries).
• Set Retention Policy: Synology offers Keep all snapshots within X days plus Long-term retention (keep one per week for N weeks, one per month for N months). The default Smart Recycle equivalent is sensible — hourly for 24h, daily for a week, weekly for a month — without exploding capacity.
• Tick Make snapshot visible if you want users to see hidden `#snapshot/` subdirectories inside the share for self-service file recovery. Off is fine if you're the only operator; restoring through the Snapshot Replication UI is just as fast.

Retention math (the part that burns capacity)

• Snapshot space consumption depends on change rate — how much of the volume's data is rewritten between snapshots. A media library with one new file per day uses almost no snapshot space; a database-backed app that churns files all day uses a lot.
• Rule of thumb: hourly snapshots for 24 hours typically cost 1-3% of volume capacity for low-churn shares, 10-20% for active shares.
• Storage Manager > Volume > Volume Usage shows how much of the volume is currently consumed by snapshots. Watch this for the first two weeks after enabling — if it's climbing toward 30%+, the retention policy is too aggressive for the change rate.
• Long-term retention is where capacity gets eaten. Keeping one snapshot per month for 12 months means a year of accumulated changes is held. Useful for legal/audit purposes; usually overkill for home use. Trim to 4 weeks + 3 months unless there's a specific reason to keep longer.

Snapshot Replication to a second NAS

• Both NAS units must run DSM with Snapshot Replication installed. The destination is registered as a Replication Server via Snapshot Replication > Replication > Add > Create replication > Shared folder > destination.
• Replication is asynchronous — schedules can be hourly, daily, or by-replication-source-snapshot. The destination holds its own snapshot history independent of the source, so you can have hourly snapshots on the source and weekly retained on the destination.
• If the destination is on the same LAN, this protects against source-NAS failure. If the destination is off-site (relative's house, office, colocated), it protects against home-loss scenarios too — but the encryption-in-transit and identity model needs to be planned (Tailscale tunnel or VPN between the sites is the common pattern).
• Snapshot Replication does NOT replace Hyper Backup. The destination NAS holds the same data in the same Synology-specific snapshot format. A bad Synology-side bug or admin-account compromise can damage both sides; Hyper Backup with encryption to a non-Synology destination is the additional layer.

Last reviewed

2026-05-18 · Reviewed by HomeTechOps. Reviewed against Synology's Snapshot Replication overview, the Btrfs-only volume requirement from DSM Storage Manager documentation, and NIST's conservative-backup framing for the snapshots-are-not-backup boundary.

Source-backed checks

HomeTechOps turns official docs and conservative safety rules into a shorter runbook. These links are the source trail for the page direction.