Quoting Hendrik Boom (hendrik@???):

[RAID1:]

> It's not backup in any normally robust sense of the word. It does
> provide a bit of backup against one potential threat -- minor
> localized hard drive failures.

Which is properly called rendundancy, in contrast to backup. (You might
continue to choose to differ, in which case we agree to disagree,
please.)

> That's why I also keep separate off-line backups.

Which is properly called backup. ;->

> TRIM because SSDs?

That's what TRIM (capitalised not as an acronym but rather because it's
a style convention for the names of ATA commands) applies to. Your
question lacks context and clarity as stated, so I don't know whether
you're saying you are fundamentally unfamiliar with the issue. You
might be saying that. If you are:

https://en.wikipedia.org/wiki/Trim_(computing)
https://wiki.debian.org/SSDOptimization
https://wiki.archlinux.org/index.php/Solid_State_Drives
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/ata/libata-core.c#n4519

Also covers block alignment and other issues raised by SSD.

> I like the checksum protection of ZFS and btrfs. If I could get it
> with ext4 I'd be happy.

Don't hold you breath waiting. ;->

> I'll have about half a gig of RAM.  Does this rule out ZFS or just 
> make it moderately slower?  I'm not going to be running millions of 
> transactions a day on my home server.    

I'm pretty sure it totally rules out ZFS. The usual RAM suggestions
start at 8GB, and go upwards from there. It's possible to have a
crawling^W running system with less (like, as low as 1GB), but you
wouldn't like it.

[btrfs:]

> Scarily beta, yes. I'd consider it if it ever stops being scarily
> beta.

Don't hold you breath waiting.