Microsoft Volume Shadow Copy Service (VSS) for Continuous Data Protection (Part 1)
Writers note: In previous analysis briefs I've written about SCR, CCR, LCR, and LLR. I want to make it clear, based on some emails I've received. The time required to configure SCR, CCR, shared-storage clustering and LLR database consistency issues make them all poor solutions for a three-nines uptime or even a two-nines uptime system. I'm clearly stating you should use InMage DR-Scout instead of these in-built patches. Here is what might be, you can print it, eight (8) pages of CMD and pencil pushing to configure SCR.
In analyzing InMage DR-Scout and the backup, archiving and recovery industry in general, I'm always digging a little deeper for success stories, technology improvements and corporate histories. In early January, Rajeev Alturi and I spoke by phone on a quiet Saturday afternoon. Rajeev and I discussed the nuances of Microsoft's VSS and how InMage leverages the technology, regardless of operating system, chipset and application system versions.
Microsoft's VSS works by using three pieces a requester, writer and provider. If you have heard about this, then skip to the last paragraph and wait for part 2 due later this week. The requester is your traditional backup solution. Requester's send collection inquiries to the application you want to protect. This application must understand the collection inquiry sent to it by the requester and needs a writer designed to support the application data and data types. The writer is written by the application developers, not the backup vendor, to ensure the most stable and consistent recoveries.
For example, Microsoft SharePoint Server 2007 and Microsoft Exchange Server 2007 both provide writers written by Microsoft and designed to support each system. The Microsoft SharePoint Server 2007 VSS writer is dependent on the Microsoft SQL Server 2005 VSS writer, a nuance that only the application administrator may be aware of. Microsoft Exchange Server 2007 has only one writer component, because Microsoft Exchange doesn't use Microsoft SQL Server to manage and maintain data. In both cases, the processing and methods for data consistency are different, only understood by the application developers and vendor. Your backup vendor isn't going to be deeply aware of Microsoft Exchange Server 2007 consistency issues, log file support, etc.
InMage DR-Scout makes the life of managing Microsoft Exchange Server 2007 much easier. Rajeev and his team have taken the time to become deeply aware of Microsoft Exchange Server 2007 issues, such that their support for data protection is very unique. InMage has taken into consideration Microsoft Exchange's use of transaction log files and realized that quiescing the database on a live system is a recipe for spilt milk, salty snicker-doodles, etc. Microsoft VSS quiescing request will be ignored by a heavily loaded Microsoft Exchange Server. If requests to quiesce are ignored, then writers and requesters do not get the needed data for continuous protection, resulting in an inconsistent database and possibly lost data.
InMage uses its knowledge of Microsoft Exchange to prevent the possibility of lost data during periods of peak performance. InMage DR-Scout continuously performs a block based copy of log files out of the Microsoft Exchange system (referred to as log shipping). Then on the target system, DR-Scout reconstructs the database using the block-copied log files. Further, InMage also performs a regular VSS call on the live Microsoft Exchange system ensuring the database is set to a consistent state. Consistent state. A database with a consistent state is a glorious thing to see during the recovery process for Microsoft Exchange.
The final piece in the VSS architecture is the provider. InMage has gone to great lengths to create a wonderful provider, something I'll talk further about in Part 2 of this analysis on "Microsoft Volume Shadow Copy Service (VSS) for Continuous Data Protection"
In analyzing InMage DR-Scout and the backup, archiving and recovery industry in general, I'm always digging a little deeper for success stories, technology improvements and corporate histories. In early January, Rajeev Alturi and I spoke by phone on a quiet Saturday afternoon. Rajeev and I discussed the nuances of Microsoft's VSS and how InMage leverages the technology, regardless of operating system, chipset and application system versions.
Microsoft's VSS works by using three pieces a requester, writer and provider. If you have heard about this, then skip to the last paragraph and wait for part 2 due later this week. The requester is your traditional backup solution. Requester's send collection inquiries to the application you want to protect. This application must understand the collection inquiry sent to it by the requester and needs a writer designed to support the application data and data types. The writer is written by the application developers, not the backup vendor, to ensure the most stable and consistent recoveries.
For example, Microsoft SharePoint Server 2007 and Microsoft Exchange Server 2007 both provide writers written by Microsoft and designed to support each system. The Microsoft SharePoint Server 2007 VSS writer is dependent on the Microsoft SQL Server 2005 VSS writer, a nuance that only the application administrator may be aware of. Microsoft Exchange Server 2007 has only one writer component, because Microsoft Exchange doesn't use Microsoft SQL Server to manage and maintain data. In both cases, the processing and methods for data consistency are different, only understood by the application developers and vendor. Your backup vendor isn't going to be deeply aware of Microsoft Exchange Server 2007 consistency issues, log file support, etc.
InMage DR-Scout makes the life of managing Microsoft Exchange Server 2007 much easier. Rajeev and his team have taken the time to become deeply aware of Microsoft Exchange Server 2007 issues, such that their support for data protection is very unique. InMage has taken into consideration Microsoft Exchange's use of transaction log files and realized that quiescing the database on a live system is a recipe for spilt milk, salty snicker-doodles, etc. Microsoft VSS quiescing request will be ignored by a heavily loaded Microsoft Exchange Server. If requests to quiesce are ignored, then writers and requesters do not get the needed data for continuous protection, resulting in an inconsistent database and possibly lost data.
InMage uses its knowledge of Microsoft Exchange to prevent the possibility of lost data during periods of peak performance. InMage DR-Scout continuously performs a block based copy of log files out of the Microsoft Exchange system (referred to as log shipping). Then on the target system, DR-Scout reconstructs the database using the block-copied log files. Further, InMage also performs a regular VSS call on the live Microsoft Exchange system ensuring the database is set to a consistent state. Consistent state. A database with a consistent state is a glorious thing to see during the recovery process for Microsoft Exchange.
The final piece in the VSS architecture is the provider. InMage has gone to great lengths to create a wonderful provider, something I'll talk further about in Part 2 of this analysis on "Microsoft Volume Shadow Copy Service (VSS) for Continuous Data Protection"
Leave a comment