[There's a reason that Yoda is the unofficial mascot of SBS.  Size indeed matters not.] So when deploying SBS 2011 how big should your partitions be? - THE OFFICIAL BLOG OF THE SBS DIVA
Mon, Feb 7 2011 23:48 bradley

So when deploying SBS 2011 how big should your partitions be?

So when deploying SBS 2011 how big should your partitions be?  Should it be one big hunking C drive?  Or should you partition it up?

I would like to hear your input on what you think is best partitioning approach with sbs 2011 for a small business that will usually deploy raid 1 or raid 5.  To tell you the truth i don't find any justification for creating more than one big c: drive.  There is no performance gain.  No backup restore gain(you need to snap c:\system anyway).  Backups are done at volume level anyway.  Is there anything you can think of?

First off.... get a group of guys and gals together at your local SMB partner group and buy each other the beverage of your choice.  If you don't have one of those, download the Eriq Neale webcast talking about SBS 2011 here: http://www.thirdtier.net/downloads/110120-SBS2011Part1.zip

Next, I'm a fan of virtualization so the partitions you do on the parent are irrelevant to what you partition on the children you do underneath.  Well I shouldn't say they are irrelevant, but they don't have to map one to one for sure.

So in an unofficial random sample of specing out hard drives... most said they'd make that c drive close to the minimum that the SBS install wanted as the first drive.

I also see the problem in choosing a backup media that is large enough.

Filed under:

# re: So when deploying SBS 2011 how big should your partitions be?

Tuesday, February 08, 2011 6:24 AM by ChrisB

We're favouring a RAID1 mirror of 146GB disks for the C: drive, so we give SBS a single partition.  Data goes on a different sent of disks.

We've spent far too many hours repartitioning small boot drives to keep servers alive in the past...

# re: So when deploying SBS 2011 how big should your partitions be?

Tuesday, February 08, 2011 8:50 AM by Turbomcp

another thing to think about is service packs/rollups and all that

these will default(especially in sbs where you cant specify where to install all the stuff it installs by default) to c:\ where you installed sbs. so that means lets say sp2 for sbs 2011 or sp3 for exchange 2010 comes out you want to install but you need atleast 5-10 gig free space and you dont have it since you partitioned your 1 tera drive as c:\ 100 gig and rest is d:\ and you already installed tons of security updates already

and one or more sp.

you move your page file but still not enoguh space....

so thats another loop hole you can get into , so better if avoided in the first place.

# re: So when deploying SBS 2011 how big should your partitions be?

Tuesday, February 08, 2011 9:03 AM by bradley

I'll do another blog.  Note I'm building a c at 120 gig and MOVING everything to other locations.   So that 120 will just be primarily the OS.

If there's a 10 gig service pack... we got a problem of bloat.

# re: So when deploying SBS 2011 how big should your partitions be?

Tuesday, February 08, 2011 9:08 AM by Turbomcp

another thing is

why on earth would you trust what microsoft specs are:)?

when they say the minimum is 80 gig you should atleast double/triple that requirement if you want to stay safe.

i mean aminimum r2 server requirements are 32 gig partition so how is 80 gig going to be enough for install and future requirements and what exactly are the benefits here(specificly when using 2 drives in raid 1 which is budget sbs install providing raid and balanced budget)

dont forget that by default page file is placed on c:\ and is exactly or 1.5 times the amount of ram which is also going to be atleast 8gig more space.

moving data to same physical device is like partitioning your home machine and moving all pictures and my documents to d:\ wher if the drive goes down you lost c: and d:\ so didnt really gain anything there....

# re: So when deploying SBS 2011 how big should your partitions be?

Tuesday, February 08, 2011 9:18 AM by bradley

I guess it's because I bugged this in the beta and got them to push up the size :-)

# re: So when deploying SBS 2011 how big should your partitions be?

Tuesday, February 08, 2011 10:49 AM by Turbomcp

hi susan

just want to clarify when i said"why on earth would you trust what microsoft specs are:)?" i didnt mean you personally i meant

dont trust any minimum or recomended microsoft settings:)

upscale it by atleast 30-40% :)

this question i just ask myself as im going to do the upgrade from 2003 to 2011 in afew days i dont just follow things just because "it always used to be like that..."

i want to understand what the meaning behind it is and in this case except for the maybe virtual pc:) claim(which is no big winner if u ask me) i havent found any other reason to do c: d: e: when you only have 2 disk in raid 1 or 3 disks in raid 5

# re: So when deploying SBS 2011 how big should your partitions be?

Tuesday, February 08, 2011 12:45 PM by Roman

I asked this same question at the MS forums and the best reason I found to make separate partitions is that Search Indexing  and Shadow Copies are enabled or disabled by partition.

# re: So when deploying SBS 2011 how big should your partitions be?

Tuesday, February 08, 2011 3:41 PM by Turbomcp

sounds like reasonable reasons

but how is creating one big c:\ blocking or limiting shadow copies?(it takes copies of shares only as far as i remeber.

indexing not sure i mean it has its default configuration which is the profiles and anything else needs to be added, so not sure how is it going to limit something when one big c:\ is there and it has buidling search to look inside the profiles directory(where by default all redirections takes place)

intially i thought the backup in sbs 2011 can create redundant backups so multiple destinations(at the same time) so i thought d:\ would be an internal backup and another one external but since that doesnt work.(it can only backup to one destination at atime) i left that idea.

anyway,i am starting to think 200gig c: and the rest d:\ for some reason(i dont know what the reason is though:))

# re: So when deploying SBS 2011 how big should your partitions be?

Tuesday, February 08, 2011 9:04 PM by JNM

Because we were running out of space and had performance issues with SBS 2003, we changed things around when we upgraded to SBS 2008 - pair of 136 mirrored for OS, pair of 136 mirrored for Exchange and four disks (spanned across two/mirrored to two) for data/WSUS/Sharepoint and 16gb ram.  Worked great! Backed up to 750gb external harddrives and store about 9 months of backups on each one. Now we're looking to upgrade to SBS 2011 standard and will have the same setup on the new server using 146 gb drives.

# @JNM

Wednesday, February 09, 2011 7:33 PM by Joe Raby

@JNM, anyone in particular:

If you're doing a new server, I would highly recommend using new drives.  Hard drive reliability is like anything: it degrades over time.  Hard drives have spinning motors, but motors that can't be serviced like the one in Sue's Mini to extend its usability.  They wear out.  If you're deploying new hardware for the processing components and software, it makes better sense to make sure your storage system is new too.

When you do decommission an old server, leave it whole and replace the entire thing.  Plan "upgrades" for your hardware refresh cycle.

# re: So when deploying SBS 2011 how big should your partitions be?

Friday, March 18, 2011 1:10 AM by SeanPT

For what it is worth in SBS2008 and SBS2011 I've been a fan of the one big fat C drive approach. This is also was my approach on XP and Vista and now on 7.

I have spent too much time re-working partitions and drives and such when running out of space.

In terms of performance I found it really hard to do a solid benchmark. So I took a VHD and copied it to identical hardware. Then on that VHD I separated data out to a seperate VHD on a seperate array.

Copy times on files were the same. Bootup and shutdown were basically the same (within 2 seconds). Doing things like moving mailboxes around in Exchange or doing a large mailbox import / export were also the same.