Microsoft Enterprise Platforms Support: Windows Server Core Team
EPS Team Blogs
Product Team Blogs
While working here at Microsoft, I have noticed over the years that many administrators have been creating large single volumes for file shares. This has become more prevalent as storage space has become cheaper. With SAN attached storage, a disk can be carved to just about any size and I have seen single file share volumes in access of 80TB.
From an administration standpoint, having a single disk or volume that can grow over time as space is needed by the users is very simple to manage. All an administrator has to do is add more space to the end of the disk and extend the volume.
So here is a question you might want to think about. What happens if that disk or volume becomes unavailable? How long will it take to get the share back online?
Those questions are some a lot of administrators do not think about. For most, it is panic and a frantic rush to get the data to the users as quickly as possible and a call to Microsoft. If you ever had this happen to your file server, I’m sure you know the feeling when all the users are not able to access their data, especially if it is someone from upper management.
My goal with this Blog is to help minimize the effect of losing shares when a disk goes bad by using multiple drives and mount points.
Below are some of the reasons using Mount Points for large file shares as an alternative to having one large, single volume is a better option.
When using mount points pointing to smaller disks, you are reducing the chance of all your users losing access to their shares in case of a disk failure. You also get a performance increase since data requests are spread out across multiple disks.
You can design this to where one disk would hold the mount points and the root share. The other disks will be used to hold folders that are split up between the users or groups of users.
In my example below, I use Disk U: as the mount point storage disk with a folder called “Users” as my root share. Then I create folders A-Z to be the mount points. The U: Disk size is 100MB
A-D – Disk1
E-H – Disk2
I-L – Disk3
M-O – Disk4
P-T – Disk5
U-Z – Disk6
In this example, if one disk goes down, you only lose 1/6th of your data or user access, not 100% as with a single large volume. The other advantage of this type of configuration is running CHKDSK or restoring data from backup will not take as long if needed.
Increasing space on the mount point disks will also be easier. As users add files to the share, you can see what drives fill up faster and only add storage to the heavily used shares. You can also rearrange or add mount point folders to better accommodate usage so data is distributed more evenly across all disks and the disks size does not grow too large.
If you are configuring drives and shares for a new file server, then setting up mount points should not be much more configuration than normal. If you are going to implement this to an existing file server, it is much more involved as you would need a redesign of your currently used LUNs and would be much more time consuming.
Below are the steps I took to make the file share and mount points on my server.
1. Create the folder structure on the mount point drive.
2. Share the folder.
3. Create the mount points for each folder and disk.
(Repeat step 3 for each folder/disk.)
4. Create user folders.
Additional information about mount points.
947021 How to configure volume mount points on a server cluster in Windows Server 2008
318534 Best Practices for Drive-Letter Assignments on a Server Cluster
812547 The Limitations of Using Mount Points on a Volume That Uses Shadow Copies in Windows Server 2003
Michael Champion Support Engineer Microsoft Enterprise Platforms Support
Hmmm...I don't get the point, what is wrong with the god old RAID?
RAID sets give good fault tolerance for hardware failures but does not protect from file system corruption, accidental deletion of a volume, or any other volume related mishap that may happen. If you ever had to run CHKDSK or restore a backup for a large file shares, you would know what I am talking about.
To give you an example, I have worked cases where customers didn't have good backups and had to run CHKDSK on volumes with 2TB+ of small files, it took almost a week to complete. Fortunately the data was still intact but if they used mount points, the file server wouldn't be completely down and running CHKDSK on that one failed volume/disk would have taken a lot less time.
So, the big benefit of having mount points is you are not putting all your eggs (data) in one basket (volume).
Thanks, I see the point now :-)
Thanks for this article, it forced me to think about large volumes from a different perspective.
What happens if the disk with the root share is lost? Is recovery just a matter of creating a new root share on a different disk and remapping your mount points? And since the root share drives are so small, do you recommend putting multiple root shares on one disk?
If the mount point disk is lost, it is a matter of recreating the mount point/folder structure and setting up any shares again. As far as having multiple root shares on the same mount point storage disk, that's something which is really an administrative decision. I personally would put them on different disks if the mount points or root shares are used for something other than user shares like Exchange or SQL.
That is a very nice blog. I have a question in my mind after reading the above post. For a existing file server if mount point are created then would there be any issues with there NTFS permissions? Is there any possibility of the NTFS shares getting effected?
I'm not totally sure what you are asking or wanting to accomplish but the mount point will take on the permissions of the parent folder or the explicit permission of the folder you created as the mount point.
I've seen lots of information about the *use* of mountpoints in 2008 clusters. The info on "backing up" the data on those mountpoints (and the associated mountpoint mappings) is pretty sparse/inexistant. Do you know where I can find info about: 1) Backing up Data on Mountpoints using DPM 2010 or DPM 2012. 2) Capturing a mountpoint configuration (script, utility, etc)?
Thanks for your help!
What`s the behavior of this in a cluster file share??