ZFS however would protect against this, in that it checksums each chunk of data. And "zfs scrub poolname" will go through and do the checksums for you in the event you are storing a lot of data and not necessarily reading/writing it often.
If you want something that will actually protect against bit level errors well, generate some extra data using an appropriate Error Correcting Code for your important archives/files. Something like what par2repair generates. This is incredibly slow compared to simple erasure codes like RAID uses, though. There are some filesystems that do this for you automatically, I wrote one:) Actually, other than that I don't know of any filesystems that do this.
If the above is impractical for performance reasons, Google recommends mirroring everything on three disks...
It looks like Joyent was able to rebuild most (all?) of their data in their ZFS data loss situation, but it could have played out drastically differently.
I'd hate to lose some of the data on that thing, though I'm currently not doing any RAID. Just a disk of important stuff rsnapshotted every 4 hours to another disk.
Also, backing up zfs is really, really easy. 48 lines of shell scripts do daily incrementals and weekly snapshot backups.
But, do yourself a favor and put /usr/gnu/bin first in your path. oh, and alias tar=gtar. Old solarisisms will otherwise be irritating.