It's been mentioned that RAID is not a backup. VERY TRUE. Keep that in mind.
You're using terabyte sized disks, which increases the chances of an unrecoverable read error, which is a MAJOR PAIN IN THE @#$. Raid 5 is almost unusable as disks get larger; you could have one of the three disks fail completely, you replace it, and that's when you discover that one of the "good" disks has a spot that can't be read from, so you end up having to completely rebuild from backup. We had that happen with a hardware-based RAID (PERC controller).
Your RAID level depends on how you're using the server. I like 1 for most of my purposes (mirroring). It has very good read times because it can spread read commands across drives, but writes can suffer somewhat. How affected it is depends on what you're using for the controller and drive speed. Go to Wikipedia and search for RAID to get a rundown of RAID levels; no one can really tell you what to definitively use without knowing your workload, the server's usage, etc.
Do not use rsync for a backup on the same computer. If your controller is fried or something goes weird on the computer itself (or the machine is damaged in flooding, fire, electrical surge) you risk the backup getting toasted too. Backup means being able to rebuild your data on new hardware if need be after a catastrophic failure.
If you're referring to a hardware RAID controller built into the motherboard-don't. don't don't don't. Motherboard RAID is cheap, crappy, and cheap, and worse than any software-implemented RAID. If you want to go through the trouble of building a production system with RAID, use either the built-in Linux/BSD software RAID or get a good RAID card like one from 3Ware. Personally for a server, I'd get a hardware card and search the specs for features like hot swap capability and lighted alarms to indicate WHICH DRIVES have failed. There's nothing wrong with performance or ability of software RAID, and it's very reliable, but there are many questions about "I have a drive that failed and don't know which one it is", and if you screw it up you can break your data set or erase the wrong data. System administration is supposed to have some element of making your life easier (hee hee!) and puzzling which drive is which cable is which mountpoint is not fun. The hardware cards are $$ but often save you much frustration when trying to puzzle out which is in need of replacement.
Don't skimp on hard drive speed. Faster, the better, especially if this is a heavy usage server. Today's gig lans can easily make the hard disk a bottleneck now for big transfers or heavy sharing.
Make sure you have a way to monitor the RAID, and make it a point to periodically check the status of your drives.
Get a good backup system in. Any fileserver should have a good second-machine backup, whether to tape or disk. If your server blows up tomorrow you should be able to get parts in and start restoring everything from scratch if need be, unless the business issuing the paychecks can survive without their server, in which case I don't know why you'd be worried about RAID.
Hope this helps!
A RAID-Z group within a ZFS pool will always lock the size to the smallest disk within the pool. So, currently, you have what is essentially a RAID-Z of 3x 40GB drives. One disk worth is dedicated to parity bits, so you've got 2x 40GB, which is 76.29 GiB.
The way that you can work around this limitation is by not using RAID-Z at all. ZFS also lets you independently set that data should be stored in at least X locations throughout the pool, preferring different disks for the extra copies when possible. Add each disk to the pool separately, then run zfs set copies=2 poolname; this will direct ZFS to store all data in at least two places.
Best Answer
Sounds like you should consider ZFS mirroring. Start off with a mirror of the 1TB disks you have now and then when you add additional drives, add mirrored pairs of same-sized disks too the pool. Once you've filled all six drive bays, you can replace the smaller disks with larger ones and increase overall pool capacity (e.g. replace a 500GB disk with a 2TB disk and let it resilver. Then replace the 2nd 500GB disk with a 2TB disk and let it resilver. On next mount you'll have 1.5TB more free space.
RAIDz is fine if you have a lot of data and want to maximize your available space (at the expense of CPU overhead, IOPS performance and expandability) but with RAIDz (like RAID5) you need to have equal sized disks (or wasted space) and decide how many disks you want in the set at creation time. Technically, with 6 disks you could start with a 3 disk RAIDz with equal sized drives and when expanding you could add a second 3 disk RAIDz set, but life's too short for stupid things like that. Just go with mirroring.