I can’t even talk during the day because of the great sucking sound coming from our microsoft infrastructure.
From a storage end, it’s even harder, because natively Microsoft doesn’t have ANY tools to unmount a filesystem or quiesce a production volume so you can take a hardware based snapshot of it.
Of course they’ve introduced VSS, which is like saying that there is never any way but their way to clone a volume.
The main problem with VSS (besides it being a product of the limited minds at microsoft) is that it’s yet another stupid host-based application that requires system resources on the host when engaged.
VSS, and most other volume “Snapshot” providers, work in the same way.Â The simplistic description is “Copy on first write.”
Let’s go over it step-by-step.
When you first initialize a shadow copy service on any system, what happens is fairly simple.Â We’ll assume that the “unit” of measure here is a track of data, (In symmetrix case, 32K)
First,Â a “cache” area is initialized to give the system a place to copy the unmodified tracks.
Second, aÂ pseudo-volume is created with nothing in it but a list of pointers to the original, production volume.Â At this point any reads to the pseudo-volume are actually reads to the production volume.
When a track is written to on the production volume the original track is copied to the cache location first, so that the original track can still be read.Â Â TheÂ pointer for that track in the pseudo-volume is then updated to point to the cached track instead of the production track.Â The production track is THEN updated with the changed information.Â Now, any read of that track on the pseudo-volume is a read from cache.
When a track is written to on the pseudo-volume, (IE changing a time-stamp on a file when backing it up), the original track is copied from the production volume to the cache first, the pseudo-volume is updated to point to the cache location, and then the CACHED TRACK is modified.Â This protects the production volume from any changes to the pseudo or backup volume.
When the Snap/Shadow session is terminated, all cached original tracks are discarded and the current production volume is all that remains.
Now this makes sense when you have an external array, such as a Symmetrix or Clariion doing the constant calculations and updates required.Â But when you get Windoze into the mix, you are taking an operating system that is already overly bloated and that likes to consume every available CPU cycle running a stupid screen saver, and giving it the very complex task of tracking every track on a harddisk volume.
That’s like giving a sixth grader some of Stephen Hawking’s more advanced theories to chew on.Â He may eventually get it right, but probably not and you’re going to spend a lot of time waiting for it.
Anyway, that’s what I have to say about that.