DB-유

Hyper Backup to Another Synology with rsync

· synology, backup, rsync

RAID protects against a dying drive, not a deleted folder, ransomware on a workstation with a mapped share, or the NAS being stolen or flooded. I stopped calling a single NAS "backed up" a long time ago. What I do now is put a second, smaller unit at a relative's house or another office and send it a nightly Hyper Backup over rsync. Cheap, off-site, and restores use the same GUI.

You need two Synology units on DSM 6.1 or newer; the destination can be a small ARM model since it only needs disk space. It has to be reachable, either through a site-to-site VPN or a DDNS name with one forwarded port. Install Hyper Backup on the source, and Hyper Backup Vault on the destination if you want to browse received backups there.

Preparing the destination NAS

Create a dedicated user and shared folder. Control Panel → User → Create: backupuser, not in the administrators group, with a long password. Control Panel → Shared Folder → Create: hb_offsite, give backupuser Read/Write and nobody else access.

Enable the rsync service: Control Panel → File Services → rsync → tick "Enable rsync service". Leave the SSH encryption port at 22 unless you have already moved SSH; Hyper Backup will use that port when transfer encryption is on. Under "Enable rsync account" you can add rsync-only accounts, but using a DSM user is simpler.

Install Hyper Backup Vault. It has no configuration of its own; it adds the ability to see incoming tasks and their versions.

Open the firewall on the destination for the source only: Control Panel → Security → Firewall → Edit Rules → Create, ports 22 and 873, source IP the source site's public address or VPN subnet.

If the destination sits behind a home router, forward TCP 22 (or your custom SSH port) to it. With transfer encryption enabled only that port is used; 873 is for unencrypted rsync and I do not forward it.

The backup task on the source

Open Hyper Backup → the plus button → Data backup task. Choose "Remote NAS device" as the destination type.

Settings on the destination page:

  • Server name or IP address: the destination's DDNS name.
  • Transfer encryption: on.
  • Port: 22.
  • Username / Password: backupuser.
  • Backup module: hb_offsite.
  • Directory: a name for this task, for example ds916-main. Hyper Backup creates ds916-main.hbk inside the share.

Next select the shared folders to back up. I exclude docker/@docker-type scratch data and anything reproducible. On the application page tick the packages whose settings you want captured (MariaDB 10, Web Station, Docker container definitions).

On the task settings page:

  • Task name: something descriptive.
  • Enable task notification: on.
  • Schedule: nightly at a quiet hour.
  • Enable integrity check schedule: monthly, with "Check backed up data" selected.
  • Enable client-side encryption: on, and store the password and the downloaded .key file somewhere that is not this NAS.
  • Enable transfer compression: on for a slow WAN link.

Rotation settings: Smart Recycle with a maximum of, say, 30 versions. Smart Recycle keeps hourly versions for a day, daily for a month, weekly beyond that, and deletes the rest.

Click Apply and run the task once by hand.

The first run over a residential upload can take days. Control Panel → Network → Traffic Control lets you limit Hyper Backup by port or by application during working hours. I always do the initial seed over the LAN with both units side by side, then move the destination off-site. Trying to seed over a home uplink was a mistake I made once. The task keeps working as long as the destination address in the task is updated (Hyper Backup → the task → Settings → Target).

Prove you can restore

After the first run, the task overview shows the size and the last successful time. That proves very little. Do the thing nobody does: a test restore. Hyper Backup → Restore → Data → pick the task → choose a version → pick a single folder → restore to a different location on the source. Compare a checksum:

md5sum /volume1/photos/2016/IMG_0001.JPG /volume1/restoretest/photos/2016/IMG_0001.JPG

On the destination, open Hyper Backup Vault; the task appears with its versions and last backup time. Trigger the integrity check once manually and read the log.

When it goes wrong

  • "Failed to connect to the destination. Please check the connection settings and try again." Check port 22 reaches the destination (ssh backupuser@dest from the source over SSH should at least prompt for a password), and that backupuser is allowed to use rsync. Control Panel → User → the user → Applications: rsync must be Allow.
  • "Authentication failed": the user's password is fine but the shared folder permission is missing, or the account belongs to a group denied rsync. Also check Control Panel → Security → Account → Auto Block on the destination; a few typos during setup and your source IP is banned.
  • The task fails at the same folder every time with "Failed to backup data": usually a file with a name Hyper Backup cannot handle or a broken symlink. The detailed log (Hyper Backup → Log → the failed entry) names the path.
  • Versions are not being deleted and the destination fills up: rotation only runs after a successful backup. A task that has been failing keeps everything. Fix the failure first.

Enable email notification on both ends. A backup that stopped silently months ago is the one failure this setup can't protect you from.