Traditionally, I've always setup a system partition and a Data partition. I'm just about to setup a new server (Windows Server 2012 R2), and while wondering how big I should make the system partition, I started to ask myself, "Do I really need partitions?"

If you make the partition too big, then that's space you're never going to use. If you make it too small, it's going to be a giant pain in the ass.

A simple Data folder gives the separation you need. Backup utilities are smart enough to deal with this structure.

So what's the advantage in Partitioning my Hard Drives?

  • Consider this Linux question: Why create many partitions? Mar 2, 2014 at 22:35
  • Thanks, I searched, but most of what I found was about what size the partition should be. Mar 2, 2014 at 22:38
  • There are advantages to multiple partitions in a few situations, but generally (if you don't have one of those special situations) they're more trouble than they're worth. Mar 3, 2014 at 1:38
  • 1
    Fragmentation-wise it definitly wouldn't hurt to use 1 partition for your OS and another for your personal files. It also makes reinstalling your OS or installing a new OS a lot easier. Most Windows Server OSes will automaticly ask for at least 2 partitions, e.g. if you want to run a WSUS-server
    – BlueCacti
    Mar 3, 2014 at 7:49

4 Answers 4


First of all, the wikipedia entry is quite complete on this regard.

I will try to explain the rational behind partitioning besides the backup/organization arguments already provided in other answers, to argue that from the performance point of view, the only advantage in partitioning is minimizing fragmentation.

OSs have to make assumptions on how the user uses and stores her data. The problem can be boiled down to the following:

Assume you have a chunk of memory, say 256B, which you can imagine as 256 boxes in a sequence.


Now, you want to store 3 files, one with 64, other with 64, other with 128 boxes: should you allocate them?

1: | 64 | 64 | 128 | or
2: | 64 | 128 | 64 | ?

It depends... on whether which chunks are going to be stored for a long time or not, and what are the most probable chunk to be saved after one of the chunks are removed.

Imagine the 2 chunks of 64 are removed from disk in the next operation a new chunk of 128 is saved. On the example 1, you can store the 128 right away, but in the second example, first you have to move the stored chunk of 128 to the border, and only then you can add the new chunk.

Now, imagine this but with all kinds of different sizes, saved in a non-trivial way (i.e. not all 4B first, then all 8B, etc.) on a giant disk (GB size). This is known to be a very difficult problem.

The OS solves this problem by using heuristics. It does not make the optimal strategy, but uses some heuristics to put the chunks in correct places. One important information is how often how large are the chunks the user/OS saves, because it provides some a priori information on the next chunks from where the OS can try to guess.

Partitioning the disk effectively tells the OS that a specific region of the disk belongs to that partition. This means that there will be no longer a one sequence of 256 boxes, but two sequences of 128 boxes (partition A and B). The OS will no longer make the assumption on where to put it: you are the one deciding by which root on your directory you choose (hand waving speaking).

Why it can improve performance?

One typical example is when you have two distinct behaviors while using the OS. For instance, the difference between:

  1. using the OS daily, which has lots of write and erase in memory, and
  2. when you store heavy files such as videos or albums which you don't change very much.

Partitioning can improve performance when you use OS daily in one way, and you use other partition to just store heavy files which you only change very rarely during the OS lifetime.

Because your behavior is consistent within each partition, the OS will likely improve its allocation, thus minimizing fragmentation.

Now, whether this is relevant or not for normal user cases, I would say no because who develops allocation strategies are smart and the heuristics are thought for those cases.

For servers and other systems, this can make a difference, but go for it after profiling.

EDIT for including SSD

My understanding is that this problem is independent of whether we talk about SSD or hard disks. The problem is very fundamental in the sense that it only requires that you want to fill a finite space with non-constant sized items that are constantly being added and removed.

  • Both your answer and the wiki article were an interesting read. Do you know how SSDs fit into this? It seems the majority of the issues refer to issues of fragmentation/disk platters/read heads, none of which apply to an SSD. (Your data-chunks has an analogous issue for SSD though that may be worth a mention - Trim en.wikipedia.org/wiki/Trim_%28computing%29)
    – RJFalconer
    Mar 4, 2014 at 16:38
  • @RJFalconer I'm very glad you found it interesting. I updated the question to address your point. Mar 4, 2014 at 17:34

The advantage is the ability to reinstall the OS without having to copy your personal files to another place and then reallocate on the brand new OS installation, since it will be in another partition.

Additionally, if you're running a server it's typically good practice to make certain service related volumes on a separate partition. That way if that service is compromised and an attacker is able to fill up that partition your OS should still be operational. Consider an FTP or database service - if the directories that are being accessed are able to be filled up to the capacity of the disk then you'll run into some serious operational problems but someone merely dumping piles and piles of data onto it, thus causing a DOS for that system. This kind of approach would be even more attractive to an attacker if there are other valuable services running on it that they'd want to disrupt such as a web server or domain controller. Arguably, this could all be mitigated with proper configuration of these services but new exploits come out daily so it never hurts to add in more layers of security when possible. (added by Bradley Forney)

But, in a end-user (users of Windows 7, Windows 8, etc) point of view (I know that the question is to a server but to those who are seeing this though Google), there is no point in partitioning if you don't reinstall your OS with frequency.

  • 1
    No. You should be making backups. Mar 2, 2014 at 23:52
  • Well, a more appropriate statement may be "without having to restore backups" – which speeds things up considerably. The operating system's partition is no place for user data, be it server or workstation.
    – Daniel B
    Mar 3, 2014 at 0:12
  • 1
    @MarcksThomas Partitions are really "backups"? If the HDD goes into malfunction, what then?
    – athosbr99
    Mar 3, 2014 at 0:23
  • 2
    -1 "there is no point". There's many reasons to partition. Logical grouping, permissions, ease of backup, extensibility (e.g. adding a bigger "games" / "media" drive to your system), ...
    – RJFalconer
    Mar 3, 2014 at 13:09
  • 1
    I don't reinstall my OS frequently, but I was sure happy I had my stuff on a separate partition when my OS suddenly crashed completely and forced me to reinstall it. So... would definitely not say "there is no point"...
    – Svish
    Mar 3, 2014 at 13:27

Years ago (Win Server 2008), there was advantage in multiple partitions:

  1. easier to get defrag to work effectively
  2. easier to get backups by partition
  3. When exchange server filled its partition, the server would NOT crash (otherwise it did).

I don't know if this is still true in Win Server 2012.


I have made a habit of making a system and a data partition. This way I can reinstall, upgrade or downgrade my OS (I do this every now and then) without losing my data. Also, I can choose to dualboot two OSs.

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