guides

Getting Started with Your Synology: Backups and Snapshots

A Synology DiskStation NAS unit
A Synology DiskStation NAS. Photo: DYVER, CC BY-SA 4.0.

Backups. Probably the part of this series that matters most, and the one people put off longest.

Worth repeating what we said in the DSM setup guide: RAID protects you from a drive dying. It does nothing for the drive that gets ransomware, the folder you delete by accident, or the NAS getting stolen, flooded, or fried. Those need real backups, and DSM hands you two different tools for two different problems.

Written for DSM 7.2, Snapshot Replication and Hyper Backup.

Two tools, two jobs

Snapshot Replication takes near-instant, space-efficient point-in-time snapshots of a Btrfs volume. It exists for “I deleted the wrong folder ten minutes ago.” Fast to restore from, and it lives on the same physical NAS as the data it’s protecting.

Hyper Backup copies your data somewhere else entirely. Another NAS, a USB or eSATA drive, a cloud target. It exists for “the NAS itself is gone,” which a snapshot sitting on that same NAS obviously can’t help with.

These aren’t alternatives. Snapshots are fast local recovery you run often. Backups are what’s left when the NAS isn’t. You want both. They cover completely different failure modes.

Step 1. Confirm you’re on Btrfs

Snapshot Replication only works on Btrfs volumes, not the older ext4 format. Check in Storage Manager → Volume. If you followed the SHR recommendation on a reasonably current DSM install, you’re almost certainly already there.

If you’re not, this is the one item on this list that needs the volume rebuilt to fix. Worth checking now instead of finding out later.

Step 2. Set up Snapshot Replication

Install Snapshot Replication from Package Center, then create a snapshot schedule for each shared folder that actually matters. Docker config volumes, documents, anything you’d be annoyed to lose an hour of.

Hourly snapshots with a sane retention window cost surprisingly little space, because Btrfs uses copy-on-write and only stores what changed rather than a full copy each time. DSM will happily keep more recent snapshots and fewer old ones automatically.

Step 3. Point Hyper Backup somewhere that isn’t this NAS

Install Hyper Backup and pick a destination that survives this NAS failing completely. A second NAS somewhere else, a cloud target (Synology C2, Backblaze B2, or any S3-compatible bucket), or at minimum an external drive you physically disconnect and store elsewhere between runs.

Back up what Snapshot Replication already covers, plus anything Docker-related. Compose files and container configs are small and genuinely painful to rebuild from memory.

An external drive that stays plugged into the NAS 24/7 is not an offsite backup. It’s a second internal drive with extra steps. Fire, flood, theft, or a bad surge takes out both. If it isn’t separated from the NAS physically or logically, it isn’t doing the job.

Step 4. Actually test a restore

A backup you’ve never restored from is a theory. Pick something low-stakes and run the restore once, right now, while it doesn’t matter. The first time shouldn’t be during an actual emergency.

That’s an unboxed NAS turned into a media server with a real safety net under it. Which puts you ahead of a surprising number of home NAS setups quietly running on “it’s been fine so far.”

Leave a comment

Your email address will not be published. Required fields are marked *