Migrating to a New Synology NAS

2019-07-06 · synology, migration, backup

Every NAS I've replaced went the same way: it ran out of bays, or the CPU stopped keeping up with what I'd piled on it. Then comes the dull part, moving the data, users and package settings with as little downtime as possible. Synology supports two very different routes, moving the drives over or restoring from a Hyper Backup, and the choice depends on whether the old drives are worth keeping.

Before anything else, check three things. Both units should be on DSM 6.x, with the new unit's DSM the same or newer. For drive migration the new model has to be on the "HDD Migration" compatibility list for the old one (Synology publishes it per model); ARM to x86 is supported, the reverse not always. And take a current Hyper Backup of the old unit whatever method you pick, because migration is exactly when a drive decides to die. I also write down every package, its version and settings, plus the network and DDNS/certificate setup.

Preparing the old NAS

Update the old unit to the latest DSM 6 version available for it, because the new unit will ship with a newer version and the migration path is only tested from current releases. Then:

Control Panel → Update & Restore → Configuration Backup → Back up configuration. This writes a .dss file containing users, groups, shared folder definitions, and most Control Panel settings. Keep it on a PC.
Export what the .dss does not include: Docker container settings (Docker → Container → select → Settings → Export), Hyper Backup task lists (just note them), Cloud Sync connections (note them; OAuth tokens do not migrate), and Let's Encrypt certificates (Control Panel → Security → Certificate → Export).
Deactivate anything tied to the hardware: Surveillance Station camera licenses must be deactivated on the old unit before they can be used on the new one. Plex should be signed out. Active Backup for Business licenses are tied to the Synology account, not the unit.
Run a full Hyper Backup one last time.

Method one: move the drives

Shut down the old NAS completely. Move the drives to the new unit in the same bay order; the order matters for SHR volumes. Power on and open http://find.synology.com. Synology Assistant shows the new unit in "Migratable" state. Choose Migration → Keep my data and most of the settings. It installs DSM on the moved system partition, which takes about ten minutes, and reboots.

After the reboot, log in with the old admin account. Volumes, shared folders, users and most packages are intact. Packages that are not compatible with the new CPU architecture are listed as "Repair needed" in Package Center; usually reinstalling them from Package Center on top of the existing data works.

Check the volume:

cat /proc/mdstat
sudo btrfs filesystem show

Everything should show as clean, not resyncing.

Method two: restore to new drives

Set up the new unit fresh with new drives, ideally with a Btrfs volume even if the old unit was ext4. Give it the same hostname and IP as the old unit will have vacated, or a temporary one. Install Hyper Backup.

Hyper Backup → Restore → Data → pick the location of the old backup (the destination NAS, or an attached USB disk). Choose "Restore system configuration" first if you want users and shared folder definitions created for you, then select the shared folders and packages to restore. Application restores recreate package settings for the packages Hyper Backup supports (MariaDB 10, Web Station, Note Station and others).

Alternatively, for the data only, rsync directly between the two units over the LAN while the old one is still up, which lets you do a first pass, then a short final pass:

sudo rsync -aHAX --numeric-ids --delete -e "ssh -p 22" /volume1/office/ admin@newnas:/volume1/office/

Numeric IDs matter here: the DSM user UIDs must already exist on the destination (restored from the .dss file) or ownership ends up wrong.

Finishing the switch

Control Panel → Network: set the old unit's IP on the new one, and change the hostname to match, so mapped drives on PCs keep working.
Re-import certificates and re-point DDNS (Control Panel → External Access → DDNS) to the new unit.
Recreate Cloud Sync connections and re-authenticate.
Hyper Backup: re-link the existing backup tasks. Create the task pointing at the existing .hbk target and Hyper Backup offers to relink rather than start a new version chain.
Docker: import the container settings, or better, run docker-compose up -d in each folder under /volume1/docker.
Task Scheduler jobs are in the .dss but scripts referenced by absolute paths must exist on the new volume.

Did it all come across?

From a Windows PC, a mapped drive should reconnect without prompting. Check the user and group counts against the old unit under Control Panel. Run every Hyper Backup task once and confirm it completes as an incremental, not a full. Run sudo synopkg list and compare with the list you took earlier. Watch Storage Manager for a scheduled data scrub result over the next week.

When it goes wrong

Synology Assistant shows "Not installed" instead of "Migratable" after moving drives: the drives were not detected in the first boot, or the new unit's DSM is older than the old one's. Power off, reseat the drives, and use the latest DSM PAT file downloaded from Synology when prompted.
After HDD migration, shared folders exist but show "The shared folder is missing" or are empty: the volume is still assembling, or a drive was placed in a different bay. Check cat /proc/mdstat; wait for the resync to finish before touching anything.
Restored files all belong to admin: the restore was done before users were created. Import the .dss configuration and run synoacltool or chown per share as needed.
Package Center shows "Repair" for Docker: normal after moving to a different CPU generation. Click Repair; containers and images under /volume1/@docker stay in place.

Drive migration is faster and keeps everything, including the accumulated mess and an ext4 volume. If the old drives are near end of life anyway, I take the clean install plus restore and start fresh on Btrfs. Downtime is only the final rsync pass.