With my IT outfit, we have templates to deploy servers with a dinky C drive/partition (10GB) and a larger D drive/partition. Why do this? Windows (at least until recently and at that minimally) has no real use of dynamic mount points in general server deployments.


So with many of the comments below a synopsis:

  1. It's faster to recover a smaller partition. This includes a corruption of NTFS,which would be kept to a paticular partition instead of messing up the enitre system.
  2. You get some protection from runnaway processes. This includes the ability to set quotas.
  3. Provides some cost savings for Raid configuration
  4. A religious hold over from the days before virtualization, raids, and high bandwidth networks.

Aside from #3 ( which, I think, is an argument against partitions), I still see no reason to have separate partitions. If you want to protect your data, wouldn't you just put it on another set of real or virtual disks or otherwise map to a shared resource somwhere else (NAS, SAN, whatever)?

  • I'm seeing some confusion in the answers between volumes and partitions. Having some data stored on a different kind of RAID container than the %SystemDrive% implies a different volume. Multiple partitions on the same volume is, I believe, what the poster is really inquiring about. Nov 14, 2009 at 3:58
  • Pretend I'm speaking about a bit larger drive. Now a days, this would be impossibly small for a server environment.
    – Mike T
    Jul 28, 2015 at 2:01
  • One good reason, if you use the server as a Domain Controller, write cache will be disabled on the drive the DC is loaded in order to protect the database from corruption. Holding files on the same drive will significantly degrade performance.
    – LPChip
    Apr 9, 2019 at 14:31

13 Answers 13


To stop data filling up your operating system volume and crashing the server.

File servers benefit from separate volumes if you use quotas, as these are usually set per volume. (e.g. Put your user's home directories on one volume, profiles on another, company data on another etc.)

p.s. 10Gb sounds too small for a system volume. After several years of windows updates and service packs, that will soon fill up.

  • 2
    Yes +1, 10GB is too small for Server 2003. Trust me, many of our 2003 VMs have <1GB free on the C: now after applying all of the latest updates. 15-20GB is more realistic.
    – Lazlow
    Nov 14, 2009 at 22:28

Restoring from backup becomes easier when program/data files are separated from the OS installation. I like to give at least 25GB to the OS partition, but the point remains the same.

  • I can understand that if we are talking just restoring the os. There are many applications, MS apps specifically, that even if you tell them to use the 'D' drive, they still want some space on the 'C' drive. Wouldn't this mean restoring the whole server anyway? If so, you aren't gaining additiona benefit from some potential system fault and causeing additional configuration to take place to get back up and running.
    – Mike T
    Nov 13, 2009 at 19:52
  • I think the situation where this help is related to restoring the data, no the OS/programs... At least in my environment restoring data is far more common then restoring an OS.
    – Zoredache
    Nov 13, 2009 at 20:03
  • @MarkM: How does restoring from backups become any easier? Can you elaborate on your reasoning? Thanks.
    – joeqwerty
    Nov 13, 2009 at 20:04
  • A 10 or 25 gb restore goes a lot faster than a 250gb restore. You can store more backups easily so a single bad backup isn't as big of an issue and it is faster to make a small backup than a big one.
    – Shial
    Nov 13, 2009 at 20:29
  • 1
    Also, in my 10 years in the IT field I've only once had to restore an entire system from backup. For me, there's no compelling reason to create multiple partitions on a single hard drive. IMHO, you're creating more problems than you're solving: you have the OS and the data contending for the same underlying physiacal disk and you're risking both your OS and your data if the drive fails. IMHO, the OS and the data should be on separate physical disks, hopefully in some form of RAID configuration.
    – joeqwerty
    Nov 14, 2009 at 0:48

Typically I don't find an advantage to making partitions.

Applications (Microsoft and others) are notorious for demanding space on %SystemDrive% even if they allow you to choose a destination directory. With the inability to have the Windows Update Automated Updates service choose not to save backups of patched files, the size of "$Uninstall$" directories under %SystemRoot% grows and grows. Having an artifically constrained %SystemDrive% has been nothing but make-work for me.

I typically put shared directories and data under a single root-level subdirectory. That satisfies my needs to keep applications and data apart.

Having said all this, generally this is a "religious" issue and I don't argue with people about it. Do what you want with your servers. Not having "data" partitions has served me well.

(Now, having separate physical volumes / spindles... that's another story.)

  • 1
    Part of the reason for separate partitions on production servers is to prevent a runaway error from damaging or filling the system partition, bringing down the server as a whole. In addition, it makes it easier to grow your data storage without messing with your system partition itself.
    – phoebus
    Nov 13, 2009 at 22:39
  • Filling any volume, OS or not, is a DoS attack. Hopefully you're using quotas or some other mechanism to prevent it from happening on any volume where that matters. Nov 14, 2009 at 3:54

Part of the reason that we do this is that if you have some sort of runaway proccess that fills up the drive, Windows doesn't crash to the ground when the disk run out of space.

The second reason we do this is to allow for different sized drives/different raid levels for our OS and data partitions. For example we would get (i'm rounding numbers and pulling them outta thin air here) 2x100GB SAS drive for an OS Mirror partition, and then 6x700GB SAS drives for a RAID 10 data partition. doing that could easily save you $1000 on the cost of the system at the end of the day.

The third reason is actually quite simple, whoever built the server with the dell CD wasn't paying attention and by default it creates a 10GB OS drive (20 on newer releases i believe).

Now as Evan has said this is really a personal preference that borders on "religious" belief. Honestly with the size of todays drives, either way will work fine. Do what you are comfortable with ... or what your corporate standards dictate.

EDIT (based on the original asker bringing up virtulization):.

The thought of virtulization brings up an interesting topic. As Evan pointed out, most of what I had to say was talking about different RAID containter. However, in my VMWare enviroement i have a base template of 20 GB. Now the interesting part comes here, all of my servers are hosted on a SAN and I have two volumes presented.

  1. the 20 GB drive that is part of my template and

  2. a variable data size Data drive that I attach per the requirements of the systems.

90% of the time these two disks are on the same RAID set, but are two different "physical" drives to the machine. As usual virtualization brings a layer of obscurity to the "standard" IT thought process.

  • I would beleive, knowing who works with me, that the default 10GB does actually come the default dell setup. The raid angle is interesting. More of an arguement for having different disks though right. Raiding on partitions would seem to negate the reason for a Raid in the first place. Wouldn't a "real" drive failure cause more havoc if it was hosting multiple partitions that no longer existed?
    – Mike T
    Nov 14, 2009 at 1:45
  • @Zypher: You're not talking about partitions anymore when you're talking about different physical spindles / RAID containers. Nov 14, 2009 at 3:55
  • @Mike T: Yes i've BTDT the first time i ran that utility... very annoying. Also a drive failure on a raid partition would actually be better than a failure on a non raid drive with multiple partitions as long as you didn't exceed the point that your raid set could recover. @Evan: you are right, to me the idea of putting multiple partitoins/mount points on a single raid volume is ... well so foreign to me at this point when i think of partitions/mount points i think of well what i wrote about.
    – Zypher
    Nov 14, 2009 at 6:29

I don't have an exact answer to your question, but I do have several anecdotes that you might find useful in designing your drive/partition setup.

(1) The corrupted NTFS
I had a server with two partitions, one for OS and one for data. At some point over the years, something went wrong with the data partition, and a single file nested about 6 levels deep became impossible to delete or rename. In the end, the only solution was to wipe the partition and reload the data back on. Obviously, it would have been much more painful without partitions.

(2) The full data partition
The same server as above, at another point in it's life, managed to end up with a completely full data partition while there were dozens of GB available on the OS partition. As a stop-gap measure, I used a junction point to temporarily store data on the OS partition until the new server arrived. It was ugly, but it worked. Avoiding partitions would have meant avoiding ugly fixes.

(3) The Server 2008 UAC
On a newer server, I discovered that you may have trouble administering any drive except the C: drive, unless you are the local Administrator or Domain Administrator. Being in the Administrators group is not sufficient. This is due to an oddity with UAC, which I have disabled for now.

(4) The Volume Shadow Copy
Shadow Copy (aka Previous Versions) is toggled on/off on a per-partition basis. If you don't want to waste space storing previous versions for a particular data set, partitions are your best ally.

My preferred course of action is to completely separate OS and Data by having a separate RAID 1 array just for the operating system. This allows a great deal of flexibility. For example, I could upgrade all the harddrives used for data storage without having to change the OS installation at all.

  • Personally, I have to discount (2), as you shouldn't let your servers get in this state. Clearly as it did happen, don't you think it would have been worse if it occurred on a single volume containing data and system?
    – Bryan
    Nov 13, 2009 at 20:51
  • @Bryan Yes, a server would never get to this state in an ideal world. But you can't always assume that the SA before you did his job right. The partitions were badly chosen (about 120 GB for OS) which was the real problem.
    – Nic
    Nov 13, 2009 at 23:07
  • On of the most interesting uses of junction point I heard of
    – Mike T
    Nov 14, 2009 at 1:19

We use multiple partitions on our servers with the C: drive dedicated to the OS. Our other partitions we use mainly for storage of data such as databases, user files/folders, shared files/folders, etc.


It depends on the service, of course, but there is value in this. As alluded to elsewhere, different partitions can have different underlaying storage characteristics. As such, different drive letters should represent different underlaying drives rather than partitions. Once upon a time it was a wise move to put your Swap file on its own partition, but that's no longer as beneficial as it once was. Otherwise, keep your C: drive for OS and obstreperous applications that refuse to go anywhere else, and your relocatable apps elsewhere.

With virtualization, you can have your C: drive be file-backed storage and yet have your D:, E:, F:, etc. drives really be NPIV direct presentations of block-level storage. Or have your OS drive be the mirrored pair of disks (which may be 72GB or 144GB at that) and your non-OS drives be a RAID10 set, or even something else entirely.


When running a Windows IIS server, we seperated the OS drive from where you put the hosted website files to prevent directory traversals.

This was a Windows 2000 issue mainly though.


If your system partition is small, it takes less time to run diagnostics and repairs on that partition, resulting in less downtime. For example, if you have an unexpected disk or filesystem problem and have to reboot to run chkdsk on a 2 TB combined system+data partition, you might not have the server back online until tomorrow. If that partition is only 20 GB, you could be back up and running in less than half an hour. You can also backup or image the partition in less time.

That said, the 10 GB limit you mentioned seems alarmingly small, since you'll quickly consume that space with service packs and hotfixes. 20-30 GB would be more suitable.


I saw no mention of Short Stroking so I'll add it here.

Smaller volumes/partitions on mechanical drives reduce access time/latency. This can noticeably increase performance in some cases.

10GB boot partitions seem overly small nowdays 25 to 80GB volumes seem more comfortable to me. No matter the actual size I don't format drives to their full capacity for multiple reasons most of which go back to performance concerns.

If the D partition on the same physical drive is something for rarely used data or emergency use only then C: still gets the benefit of the short stroke effect. The key there is keeping others from using that space as though it were primary storage. Any regular use of the secondary partition wastes this advantage.

I would also add that small partitions may allow you to use a spare 36GB or 73GB drive as a spare for a degraded RAID 1 as opposed to having to leave the array degraded until a new drive arrives. You can also use SSDs that might be on the smaller side to takeover a small partition if you haven't sized yourself out of that option.


Dont forget file fragmentation too, a data drive on a server would typically fill up with log files and constantly expanding databases. The system partition also suffers from the same issue with updates and internal logs for windows. But a fragmentation issue on the system partition will bring the entire system to a halt, where as the same issue on a data drive will only affect application performance.

There is also the issue of the drives partition table, and while it's a small point, the larger the table the slower the ability to index and search it, especially if you have massive amounts of files.


In my experience, the most important point is bad blocks and scandisk: you really don't ever want to see a 10TB volume getting bad blocks and in need of a scandisk, specially in an important server, as it may take several (or many!) hours to end, while your users are first asking for their files, then blaming the IT stuff, and finally shouting at you.

If you have partitions, bad blocks will be in a small drive (at least, those preventing your server from working), which will get scanned and fixed fast enough so your users don't shout at you (because, let's face it, they'll still blame the IT stuff).



When performing an upgrade or recovering the OS, it is much easier and cleaner when the operating system resides on a dedicated volume. In virtual environments, one can simply copy the data ".VHD" to a new server for restoring/upgrading the service.

Volume Shadow Copy Service

This functionality can only be on/off on a per volume basis. It is most efficient to dedicate a separate volume since this technology works by allocating restore points based on available free space. The more free space available, the further back one can perform a restore. The OS drive will consume space for installed updates, temporary program files, etc. Allocating previous version of this just means restore points will be shorten and isn't a good use of the technology.

Compression vs EFS

Only one of these technologies can be used on a volume so using dedicated volumes prevents conflicts.


This is more of a preference than a technical reason as it is much easier for me navigate to a different volume in contrast to a nested subfolder on the OS volume.

Same goes with applying permissions as it is easier to manage this on a per volume basis rather than nested subfolders.

OS Volume - 0 Free Space

This hasn't happened to me in quite some time but when it did, very strange things happen. If users are allowed to modify content on the OS volume (via a file share, upload large files to a database, etc.) you'll get a denial of service scenario. Resolution is much easier when this happens to a volume other than where the OS resides.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .