This is a perfect use case for ZFS. We run a number of ZoL (ZFS on Linux) filers in various backup/archival roles, and the cost savings and flexibility are great. These range in size from about 100TB to 1.6PB.

Since you are a single dev with limited experience with this, hopefully I can think of a few common gotchyas.

1) Many disagree here, but I do not think ZFS is ready to run as primary storage for say backing a vmware cluster. We've tried in the past, and there are far too many "reboot the server" style bugs when you get into heavy load. Many have been fixed, but simple things like certain types of drive failures ZFS on FreeBSD still can have issues. We've even experienced this on IllumOS/Nexenta as well. Data integrity will let you sleep at night, but don't expect 100% availability comparable to a Netapp or the like. This is why we use ZFS in a backups/archival role only, where 100% availability is not required.

2) Understand your I/O needs and how that will impact your choice of mirrored vdevs over raidz(2) vdevs. You will likely not get the space efficiency you are mentally calculating either, which is something to keep in mind. I'd take a look at the raidz efficiency calculations[0] and keep in mind you should never fill a zpool beyond 90% capacity or so.

3) Shouldn't need to be said - but run ECC memory. RAM is cheap, buy a lot.

4) For rsync based backups (assuming backing up actual user directories and such) you will have potential for a lot of small file writes. I do suggest a small SLOG (write cache) ssd for these cases, as random writes against a raidz vdev consisting of spinning rust can be rather slow. I don't see a reason for any l2arc (read cache) here.

5) You're doing a one-off. Do not go exotic on the hardware. I recommend a standard 1U server with the LSI HBA of your choice, connected to an appropriately sized SAS JBOD enclosure. We've had good luck with both HGST 4U/60 drive units, and Supermicro 4U/45 drive units depending on the density we need and if top-load is a good choice for a particular facility. I suggest avoiding top-load as your first deployment, assuming you are not space constrained. There are plenty of VARs out there who can give you a pre-packaged deal.

6) Due to the way ZFS stripes over vdevs, it's better to build out capacity up-front vs. add later if performance is a concern. This is likely much less of an issue for your use-case but is important for planning. For example if you know you will need an additional 100TB in 12mo, buy it all at once and add it to the pool day one. Don't trickle in new vdevs 8 spindles at a time.

7) This is probably the largest pain point for ZFS right now - you will have to build tooling to properly monitor and administer it. This isn't hard, but is something to very easily forget or have break and not notice if you're a single man "ops" team as your second responsibility. Remember to monitor zpool space usage and to alert early to add capacity. Stuff like a hot spares while getting better I wouldn't trust to automatically Just Work(tm) yet, so ensure you have robust drive/pool health monitoring.

8) Snapshots! Remember to use them, they are magic. znapzend is a decent tool for getting schedules going.

9) Sounds like you won't need it now, but zfs send/receive combined with snapshots are one of those life changing technologies like Tivo I don't think I could live without these days.

Overall ZFS is great, if you enjoy a little hacking this should be a fun project for you.

Edit: links, woops.

[0] https://docs.google.com/spreadsheets/d/1pdu_X2tR4ztF6_HLtJ-D...