My DS918+ started dropping SMB connections in the middle of Sunday backups. Six years of faithful service, and suddenly the little four-bay box would freeze for thirty seconds at a time whenever more than two people touched it. Rather than buy another Synology and inherit the same closed ecosystem, I decided to build a TrueNAS box and move everything over.
This is the actual log of that move. The good, the annoying, and the two hours I spent staring at a permissions error that made me question my life choices.
The starting point: what I was moving off
The old setup was a Synology DS918+ with four 4TB WD Reds in SHR (Synology Hybrid RAID), giving me roughly 11TB usable. It held about 14TB spread across two volumes once I counted the second expansion I had bolted on years earlier. Family photos, a Plex library, Time Machine backups for three Macs, and a Docker container running Home Assistant.
The new box was deliberately boring hardware: an Intel i3-12100, 32GB of ECC RAM, and six 8TB Seagate IronWolf drives. Total parts cost landed around 780 dollars, which is roughly what a comparable six-bay Synology would have cost me for the enclosure alone.
ZFS is hungry for RAM, and ECC is the reason people trust it. If you are moving irreplaceable data onto ZFS, do not cheap out on memory.
Building the ZFS pool
The first real decision was pool topology, and it matters more than any other choice you make. With six 8TB drives I went with RAIDZ2, which survives two simultaneous drive failures and gave me about 29TB usable after ZFS overhead.
I briefly considered two mirrored vdevs for faster rebuilds, but for a home archive that is mostly written once and read occasionally, RAIDZ2 wins on usable space. The official TrueNAS documentation walks through the tradeoffs if you want the deep version.
Here is how the two systems compared on paper before I moved a single byte.
| Detail | DS918+ (old) | TrueNAS build (new) |
|---|---|---|
| Layout | SHR, 4x 4TB | RAIDZ2, 6x 8TB |
| Usable space | ~11TB | ~29TB |
| Filesystem | Btrfs | ZFS |
| RAM | 4GB (non-ECC) | 32GB ECC |
| Snapshots | Btrfs, per-share | ZFS, per-dataset |
One thing I did right: I created separate datasets for photos, media, and backups instead of dumping everything into one giant share. Datasets in ZFS each get their own snapshot schedule and compression settings, and you will want that granularity later.
A mistake I see people make constantly is filling a ZFS pool close to full. Performance falls off a cliff once you cross roughly 80 percent capacity, because ZFS is a copy-on-write filesystem and needs free blocks to work efficiently. Sizing for 29TB usable when I only had 14TB to move meant I had years of headroom before that ever becomes a concern.
I also gave the box a static IP straight away and wrote it on a sticker on the case. When you are copying between two machines at 2am, you do not want to be hunting through your router for which address the new server grabbed.
Moving 14TB without losing sleep
The transfer is where people panic, so let me be specific about what actually worked. I connected both machines to the same gigabit switch and used rsync over SSH, pulling from the Synology into the TrueNAS box.
On the Synology I enabled SSH under Control Panel and made sure the rsync service was on. Then from a TrueNAS shell I ran a pull for each share, one at a time, so I could watch each finish before starting the next.
The command that did the heavy lifting looked like this:
rsync -avh --progress [email protected]:/volume1/photos/ /mnt/tank/photos/
Over plain gigabit I averaged around 108 MB/s, which meant the full 14TB took a little under 40 hours of wall-clock time across three evenings. I ran it in a tmux session so a dropped laptop connection would not kill the transfer, which is a mistake I have made before and only make once.
The single biggest time-saver was doing an initial pass, then a second rsync run the next morning. Rsync only copied the handful of files that changed overnight, so the cutover the following weekend took minutes instead of hours.
Once each dataset finished, I ran a quick sanity check comparing file counts and total size on both ends before trusting the copy. A one-line find piped into wc on each side takes seconds and catches a partial transfer before you have wiped the source. I have talked to enough people who skipped this step and regretted it that I now treat it as mandatory.
What actually broke
Now the honest part. Three things went sideways, and one of them cost me a real evening.
1. Permissions and ownership
Rsync copied the files but the ownership came across as Synology's numeric user IDs, which meant nothing to TrueNAS. Every file showed up owned by a ghost user, and SMB clients got access-denied errors. The fix was a recursive chown to my TrueNAS user and group after each dataset finished copying, plus setting the ACL type correctly on the dataset before sharing it.
2. Time Machine backups did not survive
Do not bother copying Time Machine sparsebundles across. They are tied to the old share and Apple's backup format is fussy about it. I copied mine, wasted an hour, and ended up just starting fresh Time Machine backups pointed at a new TrueNAS SMB share configured for Time Machine. Cleaner, and it worked on the first try.
3. Docker containers had to be rebuilt
My Home Assistant container from Synology's Container Manager could not be lifted directly. TrueNAS SCALE runs apps differently, so I exported my Home Assistant config folder, spun up a fresh instance, and dropped the config back in. Total downtime for that service was about 20 minutes.
4. Snapshots reset to zero
My Btrfs snapshot history did not come along, which is obvious in hindsight but stung a little. Fourteen months of Synology snapshots stayed on the old box until I wiped it. I set up ZFS snapshot tasks on day one so the new history started immediately.
Was it worth it, six months on
The TrueNAS box has been running without a single hiccup since the move, and the SMB freezing that started this whole project is gone. Scrubs run monthly and come back clean, and I get a plain email if a drive so much as coughs.
What I gained: real ZFS integrity checking, far more usable space, and hardware I can actually upgrade myself. What I gave up: the polished DSM interface that my family found genuinely friendly, and a bit of my weekend. For anyone comfortable in a terminal, that trade was easy.
If you are on the fence, keep the Synology powered off but intact for a month after you switch. I did, and knowing I had an untouched copy of everything let me sleep the entire time the new pool was proving itself.
Frequently asked questions
Can I move my Synology drives straight into a TrueNAS machine?
No. Synology uses SHR layered on mdadm and Btrfs, while TrueNAS uses ZFS, and the two formats are not compatible. You must copy data across a network from the old box to the new one, which means running both systems at the same time during the migration.
How long does it take to move several terabytes?
Over standard gigabit Ethernet you will see roughly 100-110 MB/s with rsync, so about 3 hours per terabyte. My 14TB took just under 40 hours spread across a few evenings. With 2.5GbE or faster on both ends you can cut that time roughly in half.
Do my Synology snapshots and Time Machine backups come across?
Neither transfers cleanly. Btrfs snapshots stay on the Synology and cannot be restored into ZFS, and Time Machine sparsebundles are tied to the original share. Set up fresh ZFS snapshots and new Time Machine backups on TrueNAS rather than fighting the old data.
Which ZFS pool layout should a home user pick?
For a mostly-archive home NAS with five or more drives, RAIDZ2 is the safe default because it survives two simultaneous drive failures and keeps most of your capacity. If you value fast rebuilds and can spare the space, mirrored vdevs are an alternative, but they cost you far more usable storage.
How much RAM do I need for TrueNAS with ZFS?
For a home setup, 16GB is a reasonable floor and 32GB is comfortable. ECC memory is strongly recommended because ZFS trusts what is in RAM, and ECC catches the bit errors that would otherwise slip onto disk. Do not run mission-critical data on 4GB of non-ECC RAM.
Why do I get access-denied errors after copying files with rsync?
Rsync preserves the old numeric user and group IDs, which mean nothing on the new system. Run a recursive chown to your TrueNAS user and group on each dataset after copying, and confirm the dataset ACL type is set correctly before you share it over SMB.
