Snapshot Replication on Synology Btrfs Volumes

2018-06-30 · synology, btrfs, snapshots

Most people I know with a Btrfs Synology never turn on snapshots, which is a waste. They're near-instant and cheap, and they're what I reach for when someone deletes the wrong folder. Snapshot Replication, the DSM 6 package, schedules them, applies a retention policy, and can ship them to a second Synology. It's the first thing I set up after creating shared folders.

Snapshots aren't a backup, since they live on the same disks. They are the fastest way back from an accidental delete or a ransomware run, though, and replication turns them into a real second copy.

You need a Btrfs volume (Storage Manager → Volume shows the file system) and the package installed. For replication you also need a second Btrfs Synology with the package, reachable over SSH or port 5566.

Take a manual snapshot

Snapshot Replication → Snapshots → select the shared folder → Take a snapshot. Give it a description. It completes in a second regardless of folder size because Btrfs only records the current state of the tree.

Check it from SSH:

sudo btrfs subvolume list /volume1 | grep documents

You will see the live subvolume and a snapshot under @sharesnap:

ID 259 gen 4123 top level 257 path @syno/@sharesnap/documents/GMT+02-2018.06.30-10.00.00

Schedule and retention

Snapshots → the folder → Settings → Schedule: enable, every 1 hour for a working share, daily at night for a media share. On the Retention tab:

Retention policy:      Advanced retention policy
Keep all snapshots for: 1 day
Hourly:                24
Daily:                 30
Weekly:                12
Monthly:               12
Maximum snapshots:     256

The maximum per shared folder is 1024 on most models but the UI slows down well before that, so I stay near 256. Tick Make snapshot visible on the Snapshot tab if you want users to restore for themselves from #snapshot inside the share.

Restoring

Two ways. Whole folder: Snapshot Replication → Recovery → select the shared folder → the snapshot → Restore, which rolls back the entire share (a snapshot of the current state is taken first). Individual files: browse \\nas\documents\#snapshot\GMT+02-2018.06.30-10.00.00\ from Windows Explorer, or Clone the snapshot into a new shared folder to copy from it in File Station. Windows users can also use Previous Versions in the file properties dialog if SMB is configured with Control Panel → File Services → SMB → Advanced → Enable Windows Previous Versions.

Replicating to a second NAS

On the target NAS, create a shared folder (or let the wizard create it) and an account with administrator rights for replication. On the source: Snapshot Replication → Replication → Create:

Replication type:   Shared folder
Source:             documents
Destination:        Remote Synology NAS
Server:             nas2.example.local
Account:            replicator
Destination volume: volume1
Encryption:         enabled
Schedule:           every 1 hour
Retention (remote): same as source

The first replication copies everything; afterwards only the differences between snapshots travel, which for a document share is usually a few megabytes an hour. Check progress under Replication → the task → Status.

Practice a failover

I don't trust a replica I haven't opened. Replication → select the task → Action → Test failover. The destination folder becomes writable on nas2, with the same name, while the source stays untouched. Map it, confirm the files are there, then Action → Cancel test failover. Knowing the switch works before you need it is the whole point.

Checking the numbers

sudo btrfs subvolume list /volume1 | grep -c '@sharesnap/documents'
sudo btrfs filesystem df /volume1

The count should grow by one per scheduled interval and stop at your retention limits. On the target, Snapshot Replication → Replication shows Last replication with a green status and a timestamp within the last interval. In Storage Manager → Volume, the space used by snapshots is broken out separately so you can see how much they cost.

Notes

"This shared folder does not support snapshots": the folder is on an ext4 volume, or it is an encrypted shared folder created before DSM 6.1. Snapshot Replication only supports Btrfs, and encrypted folders need a newer creation.
Replication fails with "Failed to connect to the destination. Please check the network settings": TCP 5566 is blocked by the firewall on the target, or the target account lacks administrator rights. Add a rule under Control Panel → Security → Firewall for Snapshot Replication.
Users see thousands of "snapshot" folders in Windows search results: turn off Make snapshot visible, or exclude #snapshot from Windows indexing. Previous Versions still works without visibility.
Volume fills up unexpectedly: a snapshot pins deleted data until it expires. Reduce retention on folders with churn (downloads, surveillance recordings) or exclude them from snapshots entirely.

Next I want to look at how much the churny folders really cost in snapshot space.