Jimmy You did not mention - number of users or number of concurrent users - if performance is an issue - up time requirement; 24x7 or less “in general” you gain performance by MORE SPINDLES. The reason for this is something called “head contention.” A read/write head can only be over one spot on the disk at any one point in time. The more drives you have the data spread over, the better the chance that more than one drive can get the data independent of the other. In this way, you get better performance from 4x 70GB drives than a single 280GB drive. You have 4 spindles and thus 4 independent heads to access the disk. Now the joker in this is, it also depends on where the data is spread over the 4 drives. IOW if ALL the data is on ONE drive, it makes no difference. What I don’t know is how Navision on SQL sever spreads data over multiple data files. While RAID-5 is a viable option, with the prices of drives as low as they are, RAID-5 no longer makes sense in a production environment. Even way back when, when a 4GB drive was the biggest drive out there, I used RAID-10 on my production server (the db file used 12 drives). EXPENSIVE, but I wanted the reliability/safety + performance. For my “sandbox” server where performance was not an issue, I used RAID-5. As for expansion. I recommend you size the database drives for “at least” 1 year of growth. Why, because you don’t want to have to reconfigure the server very often. Each time you do, you have to bring the system down and risk the system during the hardware reconfigure. Remember, Murphey will be waiting to do his thing. I agree with Stryk except for the transaction log. I would mirror that drive as well. Given a “clean sheet of paper” and no $ and space constraints here is my ideal configuration: c: system (mirrored, system recovery could be pretty messy and an extra mirrored disk isn’t going to cost much more) d: swap file (mirrored? not sure about mirroring this one. The need for a separate drive depends on the environment. Sometimes there is a LOT of activity on the swap file, and having it on it’s own drive reduced head contention.) e: applications (don’t have to mirror, but reinstalling or recovering application is such a PIA that I would (and did) mirror the application drive) f: transaction log file (mirrored. Because depending on the environment, this is how you recover between full db backups. Loose the transaction log, and you can only recover back to your last full db backup. ) g: db file1 (mirrored) h: db file1 (mirrored) i: db file3 (mirrored) j: db file4 (mirrored) k: online backup disk, where you can put the online backup to disk vs to tape. (again does not have to be mirrored, but as mirrored this would only be 2 large drives, why not). From this drive you take the back up to tape. Obviously you will have constraints, that will cause you to modify the above. gud luk Gary