Paul may be bucking the system,
Actually, no I wouldn't do that. Partitioning a drive like that does not help with speed. Your primary bottleneck is the drive controller. If you are using only a single drive sub-system (maybe RAID 0 or 10) with partitions you are still reading and writing thru the same controller. You are much better off using multiple real drives. Reading from primary and writing to the backup is faster that way.
Drive sub-system 1. Raid 0 - OS and FMS and live files. Only needs to be 2x whats needed for the OS, primary FMP files, the expansion needed for new data, the FMP temp files, and the PS swap files. At 50GB of on-line data maybe 200-500GB.
Drive sub-system 2. Raid 10 backup drives. LARGE,
for daily backups, how many you do is up to you but you need lots of space for changed files
for weekly backups, x4 weeks
for monthly backups, how many you keep is up to you.
For example a 50GB file set
X 4/day X 7 days
X 1/week X 4 weeks
Would be around 1400GB + 200GB + 300GB = 1.9TB so at least a 2TB backup drive system.
AND that's only for 50GB of on-line databases!!! Scale up for more on-line data or scale back the number of daily backups.
Of course this all assumes these are active changing databases with a lot of new records being added. Static lookup database (like ZIP codes) can be counted once for main and once for backups as the backups will use "hard links" for unchanged files.
The week before devcon, FMI released a white paper that describes this in a bit more detail, it should be available here in the TechNet resources.
Of all potential bottlenecks, disk i/o is the one with the biggest penalty. So having 3 separate drives, each setup according to a task is going to be fast. AND it will also facilitate any external backups you need to set up, and it will allow you to make your monitoring easier.
I had another look through the Technical Briefs and White Papers area and found the following document which has everything I was looking for: