Hacker News new | ask | show | jobs
by gregmac 1832 days ago
For my big media volume, which had existed for around 10 years, I use snapraid.

Because of several things:

* I can mix disk sizes

* I can add new disks over time as needed

* If something dies, up to the entire server, I can just stick any data disk in another system and read it

I didn't want to become a zfs expert (and the learning curve seems steep!), and I didn't want to spend thousands of dollars on new gear (dedicated NAS box and a bunch of matched-size disks).

I repurposed my old workstation into a server, spent a few hours getting it set up, and it works. I've had two disks fail (one data, one parity, and recovered from both). Every time I've added a new disk, it's been 50-100% larger than my existing disks.

I've also migrated the entire setup to a new system (newer old retired workstation), running proxmox, and was pleasantly surprised it only took about an hour to get that volume back up (incidentally, that server runs zfs as well.. I just don't use it for my large media storage volume).

2 comments

UnRaid and Synology user here and I completely agree with all your points. The knowledge that at worst I will lose the data on just 1 disk (or 2 if I fail during a rebuild) is very calming. If not for UnRaid there is no way I could manage the size of the media volume I maintain (from a time, energy, and money perspective). I mean if you know ZFS well and trust yourself then more power to you but UnRaid and friends fill a real gap.
The funny thing here is that I went with zfs lately because it saved me money. As a poor student trying to maximise gb/$, raid6/lk was the move balance point between capacity and redundancy.
The learning curve of ZFS compared to every alternative out there is significantly lower IMO. The interface is easier and the guides online are great.

There are drawbacks as the one discussed here, but as a Linux user who doesn’t want to mess up with the FS and uses ZFS for the backup server, the experience has been great so far.