ZFS suitable for strictly rsync-backup purposes?

[Hans Otto Lunde]

Hi
I'm a sysadmin and mainly a Linux-person, so I don't have any practical experience with TrueNAS and ZFS.
I like IXSystems and have their hardware running(Linux) in several places. Very pleased with them.
I bought a TrueNas Mini XL+ and WD Red NAS Pro disks to fill up the 8 bays it has.
But the machine comes with TrueNas installed and this version only supports ZFS for the storage system. So my question is:
This machine will only be used for nightly backups, using rsync to backup around 8-10 linux-servers and some other stuff.
Is it a good idea to use ZFS for this purpose? ZFS is rather demanding when it comes to ram and its COW-system in combination with maybe the RAIDZ2 could maybe be overkill for this. Will I be better of just using the old-school Linux-approach?

Danish greetings..

 

[Ericloewe]

I maintain that there are very few situations for which ZFS is unsuitable and that those that remain exist only because of very constrained environments that already implement a minimum feature set in some other way (e.g. embedded systems with checksums for regions of their flash storage and redundant copies).

Fundamentally, ZFS introduces a set of guarantees that no other filesystem offers (btrfs might, were it not a trainwreck):

• Checksums of everything - bad data is immediately identified
• Only good data or errors are returned
• Repairs are automatic and unambiguous (In most cases: some edge cases would need to test an absurd number of combinations to determine what the good data is. In these situations, the error may be treated as uncorrectable.)
• Scrubs will read everything and allow for errors to be corrected in a timely manner

And that's in addition to quality of life stuff, like:

• A sane CLI (Which I maintain that LVM and Gluster desperately need above all else)
• Large feature set for compression, checksumming and encryption
• Scalability
• Snapshots
• Replication
• etc...

So yeah, I find it hard to argue against ZFS. Not that it's perfect, but it's the best out there.

ZFS is rather demanding when it comes to ram

It's 2022, some phones have 16 GB of RAM. You didn't mention how much data you're looking at, but for simple archival stuff, 16 GB or even 32 GB are not particularly onerous and go a very long way.

COW-system

Very hard to argue against this, I have a hard time imagining a viable filesystem that guarantees atomic transitions between valid states without CoW. Hell, even NTFS does some amount of CoW.

the RAIDZ2 could maybe be overkill

I can't imagine why. It's no more overkill than RAID6 would be overkill. I would say that it allows for a very nice balance of reliability and storage efficiency, in your case with 6+2 disks. It's not like you'd do this without redundancy, a single disk dies and there goes your backup...

 

[jgreco]

It's 2022, some phones have 16 GB of RAM.

You stole my line!

will only be used for nightly backups,

RAIDZ2 could maybe be overkill for this.

So just to view this through a different set of optics, are you suggesting that you'd prefer to have something less reliable storing your backup data, the stuff that you'd be relying on in case you experienced a failure using

the old-school Linux-approach

that you are presumably using on your other servers? Using heterogeneous methods to avoid catastrophe is recommended. ZFS makes it easy to do snapshots, and there are a variety of good backup tools that can do really cool things too.

 

[Arwen]

@Hans Otto Lunde

ZFS suitable for strictly rsync-backup purposes?

Seeing as the other 2 did not mention this topic, I thought I would.

Yes, without reservation, TrueNAS can support rsync backups from Linux, (or other Unix), clients.

Now I do suggest some thoughts about:

• Network bandwidth. A simple staggered backup schedule takes care of that. (Or higher bandwidth cards, like 10Gbps on the NAS.) Of course, rsync only sends differences, so bandwidth is not wasted. Just keep in mind things can get busy on the NAS if all the clients were to backup at the same time.
• ZFS Snapshots can help too. Simply setup a daily snapshot of the client's backup dataset way after it's expected to complete it's backup. That way you have actual server states saved at the time of the backup. This more or less give continuous fulls going back as far as your storage allows.
• You can setup a different ZFS dataset for each backup client, (under the "backup" dataset for example). This allows setting different schedules or retention times for snapshots. Or, setting compression differently.
• A fast SSD or NVMe L2ARC device setup for Metadata caching might be worth while. This can speed up detecting what needs to be backed up. (That's what rsync generally does, use the date & time stamp of destination file to determine if it's older than source.)

Note that L2ARCs can't be mirrored because they contain data already in the ZFS pool. And will automatically populate as needed after any failure & replacement.

 

[Hans Otto Lunde]

Thanks for your comments.
I've set the machine up with the 8 disks in the same vdev and a 6+2 RaidZ2 configuration.
This is what I planned from reading the docs, but also what the Truenas software recommended for me to do..
It seems to run just fine. There is just one thing that bothers me.... I'll write about that in another post.

 

[anodos]

If the origin servers are Linux and have POSIX1E ACLs set on them, then you should probably use SCALE with a dataset (or datasets) with POSIX acltype. Otherwise rsync of permissions will fail.