Mount points – they’re understandably popular. And although they’ve been around for quite a while, some people have questions around their implementation. Yes, they’re really easy to set up, but you should follow some guidelines so you can take leverage advanced technologies down the road.
For the uninitiated, here’s an quick overview of mount points:
Traditionally, a windows volume (disk drive, LUN, etc) had to be mounted to a drive letter for Windows to access it. This results in a limitation of 24 hard drives that can be mounted to a system. To overcome this limitation, Microsoft introduced the ability to mount a drive on an empty directory within any NTFS filesystem. You can try it yourself next time you format a USB stick. It’s quite neat – now you can have a virtually unlimited number of drives attached to your system. You know, like UNIX. . It also makes it easier to find stuff.
Here’s an example: Let’s say I have a database with 2 data files, and 1 transaction log, and I want to keep them on separate drives for recovery and performance purposes. Instead of mounting them to letters g:\, h:\ and i:\, I can do this:
- g:\dbname\dbfile01
- g:\dbname\dbfile02
- g:\dbname\tlog
Where dbfile01, dbfile02, and tlog are all empty directories on which a drive is mounted (mount point). The directory structure is clear to anyone who looks at it, and if I need to add more drives to my database I just create a directory in dbname, and put a drive on it. I try not to put the mount points on my system drive (c:\), although I’m allowed to. The reason is that the mount point looks just like a directory – you have to know that it’s a mount point. When I have it on another drive letter, it’s clear that there’s another drive there.
So what’s a nested mount point? As the name implies, it’s where you have a mount point within a mount point. In our case, the dbname directory could be a mount point.
Are nested mount points categorically a bad idea? Absolutely not – in fact it’s a pretty common practice. The key is that there shouldn’t be unique data higher in the directory structure than a mount point. For example, this is a bad idea:
- g:\dbname\dbfile
- g:\dbname\dbfile\tlog
Where both dbfile and tlog are both mount points. First, it wouldn’t occur to another DBA that tlogs is actually a different drive. It also has implications for backup and recovery if you’re trying to leverage a volume-based backup and recovery system. The reason for this becomes clear when you start playing through a recovery scenario. Let’s say I want to restore my database, but keep my transaction log around for replay. VSS and the SQL Virtual Device Interface (VDI) backup and restore at the disk level rather than the file level. So I’ve completely replaced not just g:\dbname\dbfile, but also g:\dbname\dbfile\tlog, where the transaction log lives.
I haven’t necessarily lost any data – I can just go find the tlog drive, mount it up, and continue my recovery. But it clearly poses problems if I want to automate the process.
So this causes all sorts of confusion around whether nested mount points are supported. In the case of Replication Manager, the answer is yes, nested mount points are supported, as long the volumes in the application set are not nested within each other. To give examples, this is supported:
- g:\dbname\dbfile
- g:\dbname\tlog
Where dbname, dbfile, and tlog are all mount points, but only dbfile and tlog are part of the application set being protected.
On the other hand, this is not supported:
- g:\dbname\dbfile
- g:\dbname\dbfile\tlog
Where dbfile and tlog are mount points and both part of the application set being protected.
If you have any lessons learned about mount points you think are worth sharing, post a comment below!
Comments