Microsoft Volume Shadow Copy Service (VSS) for Continuous Data Protection (Part 2)

In part 1 of this series I discussed the requester and writer components of Microsoft Volume Shadow Copy Service (VSS).  I also mentioned some specific enhancements that InMage Systems' Rajeev Alturi's team made to DR-Scout in order to support Microsoft Exchange Server 2007 as well as what special considerations they took in order to support other application services as well.

InMage produced a VSS provider that works by copying individual blocks of data written to your physical disks. This data protection approach is lauded as the "best approach" by IBM's Haifa research facility in Israel which begs the question, "Why doesn't IBM just use or resell InMage's DR-Scout??" - but that's a blog entry for another day. Using this term "best approach" conjures up visions of snarling and barking vendors who vehemently differ on how to protect application and file based data using continuous data protection (CDP). Let's just say that both camps have arguments for why their approach is purportedly better.

Application-based CDP is a focused approach and can't protect data down to the second as many companies require. Applications must move entire objects of data at a time. For example, let's say an application stores data on a file system block by block. Once the data is written, the application is prepared to release the data to an application-based CDP service. Perhaps the extra service load on the application is minimal, but what about the application delay? An application may receive a request to replicate its data, but it may delay that request in light of performance demands and other server activity. As VSS users know, quiescing an application isn't always possible so this minimizes the effectiveness of application-based CDP.

File based CDP is much broader, in that it doesn't take into consideration application data. It simply copies file data from one system to the other. However, all files have what we security professionals like to call a "security descriptor." In Microsoft Windows a security descriptor has four key pieces:  (1) The discretionary access control list (DACL); (2) the System Access Control List (SACL); (3) the Group creator, and (4) the Owner creator.

The DACL is the list of user and group security identifiers (SIDs) that have access to the data.  SACLs provide the auditing like reads, writes, and deletes which is stored in the Windows Security Event Viewer. The Group and Owner creators are SIDs placed onto the data object when it is created. During file based replication all this, including the changes to a file, must be managed and maintained. Bottom line, this is complicated and complications don't result in .999% uptime.

The arguments for application and file based CDP are, at best, questionable which reinforces the argument for block-based CDP as the best and safest way to deliver this functionality. InMage has gone to great lengths to create an upper filter driver for the logical disk manager within the Windows operating system to support block based data protection. Moreover, the reconstruction of the block-data is done on another server using InMage Systems' industry-unique host off-loaded CDP architecture.

Windows 2000's logical disk manager (LDM) provided new functionality for object, file and disk-based management as well as block-based VSS specifications. Since InMage DR-Scout's host off-loaded block-based data protection works directly with the VSS writers, as new VSS writers are released with new application releases, InMage automatically supports them. This block-based architecture ensures DR-Scout provides data protection for both file and application data today while ensuring compatibility with future Microsoft OS releases. InMage's architecture delivers to companies the level of data protection they need now while at the same ensuring it works with future releases of Microsoft Windows.