We are looking at using a VSS aware solution to do backups on Exchange 2007 
on Windows Server 2008.  The backups would be done from the passive node of 
the CCR cluster.  I am trying to find some detailed documentation on how this 
is done so I can explain it to my backup and storage group.

Does anyone know where I might find the documentation?

There are three parts to a VSS backup solution; the writer, the requestor, 
and the provider.  The writer is built into the application, Exchange.  The 
provider is the piece that actually takes the snapshot.  You're problably 
familiar with the Microsoft Software Provider.  SAN vendors typically 
provide a hardware provider for their SAN platform.

Many providers are Copy on Write; when a snapshot is in place, overwriting 
involves copying the block out, writing it to a "difference area" and then 
overwriting the original data.  The space required for the snapshot is equal 
to the change delta between snapshots, and the performance hit is 3X for 
overwrites.   Another type of provider is the clone.  It copies out the 
whole volume on each snapshot.  The space consumes by a backup is equal to 
the size of the volume.  Yet another kind of provider is Allocate on Write. 
For this type of provider, space consumed is equal to the change delta like 
copy on write, but there is no performance penalty.  Writes always occur to 
free space, and a snapshot in place simply prevents the deallocation or 
freeing of blocks.  In short, not all providers are created equal, check 
with your vendor.

The requestor is the piece you would probably recognize as "backup software" 
it coordinates the backup between the writer and the provider, ensuring that 
IO is quiesced before the provider takes the snapshot and thawed afterwards 
so that the backup is consistent.  Verification per kb 822896 is usually 
handled by the backup software as well.  This typically involves invoking 
eseutil /k /i.  The verification of the VSS backup reads every page of the 
database and generates a lot of IO.  This is something to be aware of and 
plan for when you do your sizing.  For copy on write and allocate on write 
snapshots a number of blacks are shared between the snapshot and the 
production LUN, so it can impact production if you're not careful.

Given the above, it's understandable that COW based snapshot backups like 
those provided by DPM aren't run that often; once a day or monce a week.  To 
attain a low RPO, DPM leverages incremental backups of the logs.  Contrast 
that to an AOW snapshot like those created with the Netapp hardware provider 
which are typically run 4 to 8 times a day and can also supplement that with 
incremental copies of the logs.  With COW, you don't want to leave many 
snapshots in place; just a few and only long enough to copy them off to a 
secondary storage device or tape.  For AOW, you can have 250 snaps in place 
with negligable performance degradation.  Although either can reach an RPO 
of 15 minutes (as low as 5 for Netapp actually), the restore strategies and 
RTO can be quite different.  This is a function of how many snaps you can 
have in place.

While we're on the subject of restores, you mentioned CCR.  The Exchange 
2007 VSS writer does not support restore to the passive node.  If you take 
your backups from the passive node, then in order to restore even a single 
database you have to fail over  first.  That could painful.  Yes you do take 
the load of verification off the primary storage, but you magnify the impact 
of single store corruption.  It's an all or nothing thing.  If you have 50 
stores with 100 users per store, instead of impacting 100 users a single 
store corruption impacts 5000 users.  Fortuately you have the option of 
leveraging database prtability and restoring to an alternate server.  If all 
your clients are OL2K7, not a problem.  If they are downlevel outlook, 
you'll need to muck around with profiles (more likely distribute a prf file 
that modifies the  mailserver).  You'll need to examine the pros and cons 
here as well to determine what best fits your needs.

John







"RJ"  wrote in message 
news:12D99902-70E4-40CA-B4BB-0DD6E2B1109B@microsoft.com...
> We are looking at using a VSS aware solution to do backups on Exchange 
> 2007
> on Windows Server 2008.  The backups would be done from the passive node 
> of
> the CCR cluster.  I am trying to find some detailed documentation on how 
> this
> is done so I can explain it to my backup and storage group.
>
> Does anyone know where I might find the documentation?

"RJ"  wrote in message 
news:12D99902-70E4-40CA-B4BB-0DD6E2B1109B@microsoft.com...
> We are looking at using a VSS aware solution to do backups on Exchange 
> 2007
> on Windows Server 2008.  The backups would be done from the passive node 
> of
> the CCR cluster.  I am trying to find some detailed documentation on how 
> this
> is done so I can explain it to my backup and storage group.
>
> Does anyone know where I might find the documentation?

http://msdn2.microsoft.com/en-us/library/bb204080(EXCHG.80).aspx


-- 
Russ Kaufmann, MCSE, MCT, MCITP, MCTS, and other stuff
Microsoft
Premier Field Engineer - Exchange

John,

Thanks for this valuable information.  We were planning on performing the 
backups on the passive node to prevent creating a load on the active node.  
This would be an issue for a restore as all users on the server would be 
affected during the restore process.

I believe we currently have Netapp.  I am trying to determine whether that 
is a better solution than DPM.  I have concerns about the scripting that is 
involved with Netapp and verifying that we have a good backup.

I came across an article yesterday that states there is new functionality 
available in Exchange 2007 SP1 that checks the active database using a 
utility called Online Maintenance Checksumming.  
http://msexchangeteam.com/archive/2007/12/06/447695.aspx

What do you think?

"John Fullbright" wrote:

> There are three parts to a VSS backup solution; the writer, the requestor, 
> and the provider.  The writer is built into the application, Exchange.  The 
> provider is the piece that actually takes the snapshot.  You're problably 
> familiar with the Microsoft Software Provider.  SAN vendors typically 
> provide a hardware provider for their SAN platform.
> 
> Many providers are Copy on Write; when a snapshot is in place, overwriting 
> involves copying the block out, writing it to a "difference area" and then 
> overwriting the original data.  The space required for the snapshot is equal 
> to the change delta between snapshots, and the performance hit is 3X for 
> overwrites.   Another type of provider is the clone.  It copies out the 
> whole volume on each snapshot.  The space consumes by a backup is equal to 
> the size of the volume.  Yet another kind of provider is Allocate on Write. 
> For this type of provider, space consumed is equal to the change delta like 
> copy on write, but there is no performance penalty.  Writes always occur to 
> free space, and a snapshot in place simply prevents the deallocation or 
> freeing of blocks.  In short, not all providers are created equal, check 
> with your vendor.
> 
> The requestor is the piece you would probably recognize as "backup software" 
> it coordinates the backup between the writer and the provider, ensuring that 
> IO is quiesced before the provider takes the snapshot and thawed afterwards 
> so that the backup is consistent.  Verification per kb 822896 is usually 
> handled by the backup software as well.  This typically involves invoking 
> eseutil /k /i.  The verification of the VSS backup reads every page of the 
> database and generates a lot of IO.  This is something to be aware of and 
> plan for when you do your sizing.  For copy on write and allocate on write 
> snapshots a number of blacks are shared between the snapshot and the 
> production LUN, so it can impact production if you're not careful.
> 
> Given the above, it's understandable that COW based snapshot backups like 
> those provided by DPM aren't run that often; once a day or monce a week.  To 
> attain a low RPO, DPM leverages incremental backups of the logs.  Contrast 
> that to an AOW snapshot like those created with the Netapp hardware provider 
> which are typically run 4 to 8 times a day and can also supplement that with 
> incremental copies of the logs.  With COW, you don't want to leave many 
> snapshots in place; just a few and only long enough to copy them off to a 
> secondary storage device or tape.  For AOW, you can have 250 snaps in place 
> with negligable performance degradation.  Although either can reach an RPO 
> of 15 minutes (as low as 5 for Netapp actually), the restore strategies and 
> RTO can be quite different.  This is a function of how many snaps you can 
> have in place.
> 
> While we're on the subject of restores, you mentioned CCR.  The Exchange 
> 2007 VSS writer does not support restore to the passive node.  If you take 
> your backups from the passive node, then in order to restore even a single 
> database you have to fail over  first.  That could painful.  Yes you do take 
> the load of verification off the primary storage, but you magnify the impact 
> of single store corruption.  It's an all or nothing thing.  If you have 50 
> stores with 100 users per store, instead of impacting 100 users a single 
> store corruption impacts 5000 users.  Fortuately you have the option of 
> leveraging database prtability and restoring to an alternate server.  If all 
> your clients are OL2K7, not a problem.  If they are downlevel outlook, 
> you'll need to muck around with profiles (more likely distribute a prf file 
> that modifies the  mailserver).  You'll need to examine the pros and cons 
> here as well to determine what best fits your needs.
> 
> John
> 
> 
> 
> 
> 
> 
> 
> "RJ"  wrote in message 
> news:12D99902-70E4-40CA-B4BB-0DD6E2B1109B@microsoft.com...
> > We are looking at using a VSS aware solution to do backups on Exchange 
> > 2007
> > on Windows Server 2008.  The backups would be done from the passive node 
> > of
> > the CCR cluster.  I am trying to find some detailed documentation on how 
> > this
> > is done so I can explain it to my backup and storage group.
> >
> > Does anyone know where I might find the documentation? 
> 
> 
>

On Tue, 29 Apr 2008 07:14:03 -0700, RJ 
wrote:

>John,
>
>Thanks for this valuable information.  We were planning on performing the 
>backups on the passive node to prevent creating a load on the active node.  
>This would be an issue for a restore as all users on the server would be 
>affected during the restore process.
Sure, but thats true no matter what solution you use.
Backing up the passive node also allows you to do it during working
hours instead of overnight.

>
>I believe we currently have Netapp.  I am trying to determine whether that 
>is a better solution than DPM.  I have concerns about the scripting that is 
>involved with Netapp and verifying that we have a good backup.
>
>I came across an article yesterday that states there is new functionality 
>available in Exchange 2007 SP1 that checks the active database using a 
>utility called Online Maintenance Checksumming.  
>http://msexchangeteam.com/archive/2007/12/06/447695.aspx

Yep. Its a good thing.


>
>What do you think?
>
>"John Fullbright" wrote:
>
>> There are three parts to a VSS backup solution; the writer, the requestor, 
>> and the provider.  The writer is built into the application, Exchange.  The 
>> provider is the piece that actually takes the snapshot.  You're problably 
>> familiar with the Microsoft Software Provider.  SAN vendors typically 
>> provide a hardware provider for their SAN platform.
>> 
>> Many providers are Copy on Write; when a snapshot is in place, overwriting 
>> involves copying the block out, writing it to a "difference area" and then 
>> overwriting the original data.  The space required for the snapshot is equal 
>> to the change delta between snapshots, and the performance hit is 3X for 
>> overwrites.   Another type of provider is the clone.  It copies out the 
>> whole volume on each snapshot.  The space consumes by a backup is equal to 
>> the size of the volume.  Yet another kind of provider is Allocate on Write. 
>> For this type of provider, space consumed is equal to the change delta like 
>> copy on write, but there is no performance penalty.  Writes always occur to 
>> free space, and a snapshot in place simply prevents the deallocation or 
>> freeing of blocks.  In short, not all providers are created equal, check 
>> with your vendor.
>> 
>> The requestor is the piece you would probably recognize as "backup software" 
>> it coordinates the backup between the writer and the provider, ensuring that 
>> IO is quiesced before the provider takes the snapshot and thawed afterwards 
>> so that the backup is consistent.  Verification per kb 822896 is usually 
>> handled by the backup software as well.  This typically involves invoking 
>> eseutil /k /i.  The verification of the VSS backup reads every page of the 
>> database and generates a lot of IO.  This is something to be aware of and 
>> plan for when you do your sizing.  For copy on write and allocate on write 
>> snapshots a number of blacks are shared between the snapshot and the 
>> production LUN, so it can impact production if you're not careful.
>> 
>> Given the above, it's understandable that COW based snapshot backups like 
>> those provided by DPM aren't run that often; once a day or monce a week.  To 
>> attain a low RPO, DPM leverages incremental backups of the logs.  Contrast 
>> that to an AOW snapshot like those created with the Netapp hardware provider 
>> which are typically run 4 to 8 times a day and can also supplement that with 
>> incremental copies of the logs.  With COW, you don't want to leave many 
>> snapshots in place; just a few and only long enough to copy them off to a 
>> secondary storage device or tape.  For AOW, you can have 250 snaps in place 
>> with negligable performance degradation.  Although either can reach an RPO 
>> of 15 minutes (as low as 5 for Netapp actually), the restore strategies and 
>> RTO can be quite different.  This is a function of how many snaps you can 
>> have in place.
>> 
>> While we're on the subject of restores, you mentioned CCR.  The Exchange 
>> 2007 VSS writer does not support restore to the passive node.  If you take 
>> your backups from the passive node, then in order to restore even a single 
>> database you have to fail over  first.  That could painful.  Yes you do take 
>> the load of verification off the primary storage, but you magnify the impact 
>> of single store corruption.  It's an all or nothing thing.  If you have 50 
>> stores with 100 users per store, instead of impacting 100 users a single 
>> store corruption impacts 5000 users.  Fortuately you have the option of 
>> leveraging database prtability and restoring to an alternate server.  If all 
>> your clients are OL2K7, not a problem.  If they are downlevel outlook, 
>> you'll need to muck around with profiles (more likely distribute a prf file 
>> that modifies the  mailserver).  You'll need to examine the pros and cons 
>> here as well to determine what best fits your needs.
>> 
>> John
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> "RJ"  wrote in message 
>> news:12D99902-70E4-40CA-B4BB-0DD6E2B1109B@microsoft.com...
>> > We are looking at using a VSS aware solution to do backups on Exchange 
>> > 2007
>> > on Windows Server 2008.  The backups would be done from the passive node 
>> > of
>> > the CCR cluster.  I am trying to find some detailed documentation on how 
>> > this
>> > is done so I can explain it to my backup and storage group.
>> >
>> > Does anyone know where I might find the documentation? 
>> 
>> 
>>

Better is a relative term.  You need to define your requirement first. 
Depending on the requirement, either may work well for you.    If you find 
you need more than a couple snapshots in place at any given time for a given 
volume to meet your requirement, then the Netapp hardware VSS provider has a 
clear performance advantage over the MS software provider used by DPM which 
will impact your storage sizing.

The online checksumming during maintenance process can be enabled, and it's 
designed to checksum the active node when you do your backup and verify 
against the passive node.  With both DPM and Netapp's SME you have the 
option of deferring or not doing a verification.  I would go ahead and 
verify the passive copy even if you enable this feature.  I don't believe 
I've seen any guidance on using online maintenance checksumming instead of a 
verify.  It seems to me to be a supplemental thing you can do to verify the 
consitency of the active copy in addition to the eseutil verification of the 
passive copy.  Perhaps Scott or someone else from MS could clarify here.

For a CCR cluster, what does your connectivity look like between the nodes? 
To fill the gap for a single database failure, you could do a restore to 
alternate server instead of failing the whole cluster over.  Exploitning 
database portability requires a little planning up front.  Each SG must be 
uniquely named across your org.  I would factor this into your design to at 
least leave that option open.  SME supports restoring to an alternate 
server.  SME can also restore to the passive node (it fails the cluster over 
first because there is no Exchange VSS writer support for restore to a 
passive node).

There's no scripting involved in verifying a backup with SME 4.X.  Netapp 
does follows 822896 as required by MS, but the application handles this when 
you check the box to verify a backup.  If you backup with SME and have 
snapmirrored the LUNs to another storage device, you can verify againt the 
snapmirror target as well.  You can verify on the host, or specify a remote 
verification server to attach to the snapshots and run the verification. 
With DPM you can verify locally or specify a remote server to do the 
verification as well.  The only scripting for SME involves commands you 
would run after a backup; like snapvaulting to secondary storage or updating 
a snapmirrored volume after the snapshot.


John

"RJ"  wrote in message 
news:A7068E6E-FDFA-4431-A9AA-55D6EC1A3AFF@microsoft.com...
> John,
>
> Thanks for this valuable information.  We were planning on performing the
> backups on the passive node to prevent creating a load on the active node.
> This would be an issue for a restore as all users on the server would be
> affected during the restore process.
>
> I believe we currently have Netapp.  I am trying to determine whether that
> is a better solution than DPM.  I have concerns about the scripting that 
> is
> involved with Netapp and verifying that we have a good backup.
>
> I came across an article yesterday that states there is new functionality
> available in Exchange 2007 SP1 that checks the active database using a
> utility called Online Maintenance Checksumming.
> http://msexchangeteam.com/archive/2007/12/06/447695.aspx
>
> What do you think?
>
> "John Fullbright" wrote:
>
>> There are three parts to a VSS backup solution; the writer, the 
>> requestor,
>> and the provider.  The writer is built into the application, Exchange. 
>> The
>> provider is the piece that actually takes the snapshot.  You're problably
>> familiar with the Microsoft Software Provider.  SAN vendors typically
>> provide a hardware provider for their SAN platform.
>>
>> Many providers are Copy on Write; when a snapshot is in place, 
>> overwriting
>> involves copying the block out, writing it to a "difference area" and 
>> then
>> overwriting the original data.  The space required for the snapshot is 
>> equal
>> to the change delta between snapshots, and the performance hit is 3X for
>> overwrites.   Another type of provider is the clone.  It copies out the
>> whole volume on each snapshot.  The space consumes by a backup is equal 
>> to
>> the size of the volume.  Yet another kind of provider is Allocate on 
>> Write.
>> For this type of provider, space consumed is equal to the change delta 
>> like
>> copy on write, but there is no performance penalty.  Writes always occur 
>> to
>> free space, and a snapshot in place simply prevents the deallocation or
>> freeing of blocks.  In short, not all providers are created equal, check
>> with your vendor.
>>
>> The requestor is the piece you would probably recognize as "backup 
>> software"
>> it coordinates the backup between the writer and the provider, ensuring 
>> that
>> IO is quiesced before the provider takes the snapshot and thawed 
>> afterwards
>> so that the backup is consistent.  Verification per kb 822896 is usually
>> handled by the backup software as well.  This typically involves invoking
>> eseutil /k /i.  The verification of the VSS backup reads every page of 
>> the
>> database and generates a lot of IO.  This is something to be aware of and
>> plan for when you do your sizing.  For copy on write and allocate on 
>> write
>> snapshots a number of blacks are shared between the snapshot and the
>> production LUN, so it can impact production if you're not careful.
>>
>> Given the above, it's understandable that COW based snapshot backups like
>> those provided by DPM aren't run that often; once a day or monce a week. 
>> To
>> attain a low RPO, DPM leverages incremental backups of the logs. 
>> Contrast
>> that to an AOW snapshot like those created with the Netapp hardware 
>> provider
>> which are typically run 4 to 8 times a day and can also supplement that 
>> with
>> incremental copies of the logs.  With COW, you don't want to leave many
>> snapshots in place; just a few and only long enough to copy them off to a
>> secondary storage device or tape.  For AOW, you can have 250 snaps in 
>> place
>> with negligable performance degradation.  Although either can reach an 
>> RPO
>> of 15 minutes (as low as 5 for Netapp actually), the restore strategies 
>> and
>> RTO can be quite different.  This is a function of how many snaps you can
>> have in place.
>>
>> While we're on the subject of restores, you mentioned CCR.  The Exchange
>> 2007 VSS writer does not support restore to the passive node.  If you 
>> take
>> your backups from the passive node, then in order to restore even a 
>> single
>> database you have to fail over  first.  That could painful.  Yes you do 
>> take
>> the load of verification off the primary storage, but you magnify the 
>> impact
>> of single store corruption.  It's an all or nothing thing.  If you have 
>> 50
>> stores with 100 users per store, instead of impacting 100 users a single
>> store corruption impacts 5000 users.  Fortuately you have the option of
>> leveraging database prtability and restoring to an alternate server.  If 
>> all
>> your clients are OL2K7, not a problem.  If they are downlevel outlook,
>> you'll need to muck around with profiles (more likely distribute a prf 
>> file
>> that modifies the  mailserver).  You'll need to examine the pros and cons
>> here as well to determine what best fits your needs.
>>
>> John
>>
>>
>>
>>
>>
>>
>>
>> "RJ"  wrote in message
>> news:12D99902-70E4-40CA-B4BB-0DD6E2B1109B@microsoft.com...
>> > We are looking at using a VSS aware solution to do backups on Exchange
>> > 2007
>> > on Windows Server 2008.  The backups would be done from the passive 
>> > node
>> > of
>> > the CCR cluster.  I am trying to find some detailed documentation on 
>> > how
>> > this
>> > is done so I can explain it to my backup and storage group.
>> >
>> > Does anyone know where I might find the documentation?
>>
>>
>>

We currently have a 1Gb connection between the two datacenters.

So, the verification that is done is that performed on the snapped copy of 
the database?  Is that then how Exchange knows that there was a valid backup 
of the database and the logs can be purged and database marked as backed up?

I apologize if these questions sound silly, but I am trying to understand 
the VSS process.

"John Fullbright" wrote:

> Better is a relative term.  You need to define your requirement first. 
> Depending on the requirement, either may work well for you.    If you find 
> you need more than a couple snapshots in place at any given time for a given 
> volume to meet your requirement, then the Netapp hardware VSS provider has a 
> clear performance advantage over the MS software provider used by DPM which 
> will impact your storage sizing.
> 
> The online checksumming during maintenance process can be enabled, and it's 
> designed to checksum the active node when you do your backup and verify 
> against the passive node.  With both DPM and Netapp's SME you have the 
> option of deferring or not doing a verification.  I would go ahead and 
> verify the passive copy even if you enable this feature.  I don't believe 
> I've seen any guidance on using online maintenance checksumming instead of a 
> verify.  It seems to me to be a supplemental thing you can do to verify the 
> consitency of the active copy in addition to the eseutil verification of the 
> passive copy.  Perhaps Scott or someone else from MS could clarify here.
> 
> For a CCR cluster, what does your connectivity look like between the nodes? 
> To fill the gap for a single database failure, you could do a restore to 
> alternate server instead of failing the whole cluster over.  Exploitning 
> database portability requires a little planning up front.  Each SG must be 
> uniquely named across your org.  I would factor this into your design to at 
> least leave that option open.  SME supports restoring to an alternate 
> server.  SME can also restore to the passive node (it fails the cluster over 
> first because there is no Exchange VSS writer support for restore to a 
> passive node).
> 
> There's no scripting involved in verifying a backup with SME 4.X.  Netapp 
> does follows 822896 as required by MS, but the application handles this when 
> you check the box to verify a backup.  If you backup with SME and have 
> snapmirrored the LUNs to another storage device, you can verify againt the 
> snapmirror target as well.  You can verify on the host, or specify a remote 
> verification server to attach to the snapshots and run the verification. 
> With DPM you can verify locally or specify a remote server to do the 
> verification as well.  The only scripting for SME involves commands you 
> would run after a backup; like snapvaulting to secondary storage or updating 
> a snapmirrored volume after the snapshot.
> 
> 
> John
> 
> "RJ"  wrote in message 
> news:A7068E6E-FDFA-4431-A9AA-55D6EC1A3AFF@microsoft.com...
> > John,
> >
> > Thanks for this valuable information.  We were planning on performing the
> > backups on the passive node to prevent creating a load on the active node.
> > This would be an issue for a restore as all users on the server would be
> > affected during the restore process.
> >
> > I believe we currently have Netapp.  I am trying to determine whether that
> > is a better solution than DPM.  I have concerns about the scripting that 
> > is
> > involved with Netapp and verifying that we have a good backup.
> >
> > I came across an article yesterday that states there is new functionality
> > available in Exchange 2007 SP1 that checks the active database using a
> > utility called Online Maintenance Checksumming.
> > http://msexchangeteam.com/archive/2007/12/06/447695.aspx
> >
> > What do you think?
> >
> > "John Fullbright" wrote:
> >
> >> There are three parts to a VSS backup solution; the writer, the 
> >> requestor,
> >> and the provider.  The writer is built into the application, Exchange. 
> >> The
> >> provider is the piece that actually takes the snapshot.  You're problably
> >> familiar with the Microsoft Software Provider.  SAN vendors typically
> >> provide a hardware provider for their SAN platform.
> >>
> >> Many providers are Copy on Write; when a snapshot is in place, 
> >> overwriting
> >> involves copying the block out, writing it to a "difference area" and 
> >> then
> >> overwriting the original data.  The space required for the snapshot is 
> >> equal
> >> to the change delta between snapshots, and the performance hit is 3X for
> >> overwrites.   Another type of provider is the clone.  It copies out the
> >> whole volume on each snapshot.  The space consumes by a backup is equal 
> >> to
> >> the size of the volume.  Yet another kind of provider is Allocate on 
> >> Write.
> >> For this type of provider, space consumed is equal to the change delta 
> >> like
> >> copy on write, but there is no performance penalty.  Writes always occur 
> >> to
> >> free space, and a snapshot in place simply prevents the deallocation or
> >> freeing of blocks.  In short, not all providers are created equal, check
> >> with your vendor.
> >>
> >> The requestor is the piece you would probably recognize as "backup 
> >> software"
> >> it coordinates the backup between the writer and the provider, ensuring 
> >> that
> >> IO is quiesced before the provider takes the snapshot and thawed 
> >> afterwards
> >> so that the backup is consistent.  Verification per kb 822896 is usually
> >> handled by the backup software as well.  This typically involves invoking
> >> eseutil /k /i.  The verification of the VSS backup reads every page of 
> >> the
> >> database and generates a lot of IO.  This is something to be aware of and
> >> plan for when you do your sizing.  For copy on write and allocate on 
> >> write
> >> snapshots a number of blacks are shared between the snapshot and the
> >> production LUN, so it can impact production if you're not careful.
> >>
> >> Given the above, it's understandable that COW based snapshot backups like
> >> those provided by DPM aren't run that often; once a day or monce a week. 
> >> To
> >> attain a low RPO, DPM leverages incremental backups of the logs. 
> >> Contrast
> >> that to an AOW snapshot like those created with the Netapp hardware 
> >> provider
> >> which are typically run 4 to 8 times a day and can also supplement that 
> >> with
> >> incremental copies of the logs.  With COW, you don't want to leave many
> >> snapshots in place; just a few and only long enough to copy them off to a
> >> secondary storage device or tape.  For AOW, you can have 250 snaps in 
> >> place
> >> with negligable performance degradation.  Although either can reach an 
> >> RPO
> >> of 15 minutes (as low as 5 for Netapp actually), the restore strategies 
> >> and
> >> RTO can be quite different.  This is a function of how many snaps you can
> >> have in place.
> >>
> >> While we're on the subject of restores, you mentioned CCR.  The Exchange
> >> 2007 VSS writer does not support restore to the passive node.  If you 
> >> take
> >> your backups from the passive node, then in order to restore even a 
> >> single
> >> database you have to fail over  first.  That could painful.  Yes you do 
> >> take
> >> the load of verification off the primary storage, but you magnify the 
> >> impact
> >> of single store corruption.  It's an all or nothing thing.  If you have 
> >> 50
> >> stores with 100 users per store, instead of impacting 100 users a single
> >> store corruption impacts 5000 users.  Fortuately you have the option of
> >> leveraging database prtability and restoring to an alternate server.  If 
> >> all
> >> your clients are OL2K7, not a problem.  If they are downlevel outlook,
> >> you'll need to muck around with profiles (more likely distribute a prf 
> >> file
> >> that modifies the  mailserver).  You'll need to examine the pros and cons
> >> here as well to determine what best fits your needs.
> >>
> >> John
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> "RJ"  wrote in message
> >> news:12D99902-70E4-40CA-B4BB-0DD6E2B1109B@microsoft.com...
> >> > We are looking at using a VSS aware solution to do backups on Exchange
> >> > 2007
> >> > on Windows Server 2008.  The backups would be done from the passive 
> >> > node
> >> > of
> >> > the CCR cluster.  I am trying to find some detailed documentation on 
> >> > how
> >> > this
> >> > is done so I can explain it to my backup and storage group.
> >> >
> >> > Does anyone know where I might find the documentation?
> >>
> >>
> >> 
> 
> 
>

You verify the snapshot, yes.  The verification process reads each page of 
the database and the header of each log file.  SME will archive the logs as 
well so that you can do an up to the minute restore.  The archived logs are 
moved to a subdirectory of the snapinfo directory specific to a given 
snapshot, and the logs in your log lun are truncated.  If the snapinfo 
directory is on the same lun as the logs, you can choose to use hard links 
to archive log files.

If you have good connectivity between the datacenters, you may want to look 
at using database portability in restore cases where you do not want to fail 
the entire cluster over.  To use database portability, each SG in your must 
be uniquely named.  Instead of using a convertion where server mail01 has 
sg1, sg1, sg3, and mail02 has sg1, sg2, etc., use one like mail01_sg1, 
mail01_sg2, mail02_sg1, etc..  This way, when you do a restore to alternate 
server, the SG names don't conflict.  It doen't involve any additional 
hardware or software, or for that matter cost anything to do this.  It does 
leave your options open so that if you do find you want to restore a single 
SG somewhere else, then you can.



"RJ"  wrote in message 
news:449E80A0-3250-4A06-B7DE-AACE57C60652@microsoft.com...
> We currently have a 1Gb connection between the two datacenters.
>
> So, the verification that is done is that performed on the snapped copy of
> the database?  Is that then how Exchange knows that there was a valid 
> backup
> of the database and the logs can be purged and database marked as backed 
> up?
>
> I apologize if these questions sound silly, but I am trying to understand
> the VSS process.
>
> "John Fullbright" wrote:
>
>> Better is a relative term.  You need to define your requirement first.
>> Depending on the requirement, either may work well for you.    If you 
>> find
>> you need more than a couple snapshots in place at any given time for a 
>> given
>> volume to meet your requirement, then the Netapp hardware VSS provider 
>> has a
>> clear performance advantage over the MS software provider used by DPM 
>> which
>> will impact your storage sizing.
>>
>> The online checksumming during maintenance process can be enabled, and 
>> it's
>> designed to checksum the active node when you do your backup and verify
>> against the passive node.  With both DPM and Netapp's SME you have the
>> option of deferring or not doing a verification.  I would go ahead and
>> verify the passive copy even if you enable this feature.  I don't believe
>> I've seen any guidance on using online maintenance checksumming instead 
>> of a
>> verify.  It seems to me to be a supplemental thing you can do to verify 
>> the
>> consitency of the active copy in addition to the eseutil verification of 
>> the
>> passive copy.  Perhaps Scott or someone else from MS could clarify here.
>>
>> For a CCR cluster, what does your connectivity look like between the 
>> nodes?
>> To fill the gap for a single database failure, you could do a restore to
>> alternate server instead of failing the whole cluster over.  Exploitning
>> database portability requires a little planning up front.  Each SG must 
>> be
>> uniquely named across your org.  I would factor this into your design to 
>> at
>> least leave that option open.  SME supports restoring to an alternate
>> server.  SME can also restore to the passive node (it fails the cluster 
>> over
>> first because there is no Exchange VSS writer support for restore to a
>> passive node).
>>
>> There's no scripting involved in verifying a backup with SME 4.X.  Netapp
>> does follows 822896 as required by MS, but the application handles this 
>> when
>> you check the box to verify a backup.  If you backup with SME and have
>> snapmirrored the LUNs to another storage device, you can verify againt 
>> the
>> snapmirror target as well.  You can verify on the host, or specify a 
>> remote
>> verification server to attach to the snapshots and run the verification.
>> With DPM you can verify locally or specify a remote server to do the
>> verification as well.  The only scripting for SME involves commands you
>> would run after a backup; like snapvaulting to secondary storage or 
>> updating
>> a snapmirrored volume after the snapshot.
>>
>>
>> John
>>
>> "RJ"  wrote in message
>> news:A7068E6E-FDFA-4431-A9AA-55D6EC1A3AFF@microsoft.com...
>> > John,
>> >
>> > Thanks for this valuable information.  We were planning on performing 
>> > the
>> > backups on the passive node to prevent creating a load on the active 
>> > node.
>> > This would be an issue for a restore as all users on the server would 
>> > be
>> > affected during the restore process.
>> >
>> > I believe we currently have Netapp.  I am trying to determine whether 
>> > that
>> > is a better solution than DPM.  I have concerns about the scripting 
>> > that
>> > is
>> > involved with Netapp and verifying that we have a good backup.
>> >
>> > I came across an article yesterday that states there is new 
>> > functionality
>> > available in Exchange 2007 SP1 that checks the active database using a
>> > utility called Online Maintenance Checksumming.
>> > http://msexchangeteam.com/archive/2007/12/06/447695.aspx
>> >
>> > What do you think?
>> >
>> > "John Fullbright" wrote:
>> >
>> >> There are three parts to a VSS backup solution; the writer, the
>> >> requestor,
>> >> and the provider.  The writer is built into the application, Exchange.
>> >> The
>> >> provider is the piece that actually takes the snapshot.  You're 
>> >> problably
>> >> familiar with the Microsoft Software Provider.  SAN vendors typically
>> >> provide a hardware provider for their SAN platform.
>> >>
>> >> Many providers are Copy on Write; when a snapshot is in place,
>> >> overwriting
>> >> involves copying the block out, writing it to a "difference area" and
>> >> then
>> >> overwriting the original data.  The space required for the snapshot is
>> >> equal
>> >> to the change delta between snapshots, and the performance hit is 3X 
>> >> for
>> >> overwrites.   Another type of provider is the clone.  It copies out 
>> >> the
>> >> whole volume on each snapshot.  The space consumes by a backup is 
>> >> equal
>> >> to
>> >> the size of the volume.  Yet another kind of provider is Allocate on
>> >> Write.
>> >> For this type of provider, space consumed is equal to the change delta
>> >> like
>> >> copy on write, but there is no performance penalty.  Writes always 
>> >> occur
>> >> to
>> >> free space, and a snapshot in place simply prevents the deallocation 
>> >> or
>> >> freeing of blocks.  In short, not all providers are created equal, 
>> >> check
>> >> with your vendor.
>> >>
>> >> The requestor is the piece you would probably recognize as "backup
>> >> software"
>> >> it coordinates the backup between the writer and the provider, 
>> >> ensuring
>> >> that
>> >> IO is quiesced before the provider takes the snapshot and thawed
>> >> afterwards
>> >> so that the backup is consistent.  Verification per kb 822896 is 
>> >> usually
>> >> handled by the backup software as well.  This typically involves 
>> >> invoking
>> >> eseutil /k /i.  The verification of the VSS backup reads every page of
>> >> the
>> >> database and generates a lot of IO.  This is something to be aware of 
>> >> and
>> >> plan for when you do your sizing.  For copy on write and allocate on
>> >> write
>> >> snapshots a number of blacks are shared between the snapshot and the
>> >> production LUN, so it can impact production if you're not careful.
>> >>
>> >> Given the above, it's understandable that COW based snapshot backups 
>> >> like
>> >> those provided by DPM aren't run that often; once a day or monce a 
>> >> week.
>> >> To
>> >> attain a low RPO, DPM leverages incremental backups of the logs.
>> >> Contrast
>> >> that to an AOW snapshot like those created with the Netapp hardware
>> >> provider
>> >> which are typically run 4 to 8 times a day and can also supplement 
>> >> that
>> >> with
>> >> incremental copies of the logs.  With COW, you don't want to leave 
>> >> many
>> >> snapshots in place; just a few and only long enough to copy them off 
>> >> to a
>> >> secondary storage device or tape.  For AOW, you can have 250 snaps in
>> >> place
>> >> with negligable performance degradation.  Although either can reach an
>> >> RPO
>> >> of 15 minutes (as low as 5 for Netapp actually), the restore 
>> >> strategies
>> >> and
>> >> RTO can be quite different.  This is a function of how many snaps you 
>> >> can
>> >> have in place.
>> >>
>> >> While we're on the subject of restores, you mentioned CCR.  The 
>> >> Exchange
>> >> 2007 VSS writer does not support restore to the passive node.  If you
>> >> take
>> >> your backups from the passive node, then in order to restore even a
>> >> single
>> >> database you have to fail over  first.  That could painful.  Yes you 
>> >> do
>> >> take
>> >> the load of verification off the primary storage, but you magnify the
>> >> impact
>> >> of single store corruption.  It's an all or nothing thing.  If you 
>> >> have
>> >> 50
>> >> stores with 100 users per store, instead of impacting 100 users a 
>> >> single
>> >> store corruption impacts 5000 users.  Fortuately you have the option 
>> >> of
>> >> leveraging database prtability and restoring to an alternate server. 
>> >> If
>> >> all
>> >> your clients are OL2K7, not a problem.  If they are downlevel outlook,
>> >> you'll need to muck around with profiles (more likely distribute a prf
>> >> file
>> >> that modifies the  mailserver).  You'll need to examine the pros and 
>> >> cons
>> >> here as well to determine what best fits your needs.
>> >>
>> >> John
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> "RJ"  wrote in message
>> >> news:12D99902-70E4-40CA-B4BB-0DD6E2B1109B@microsoft.com...
>> >> > We are looking at using a VSS aware solution to do backups on 
>> >> > Exchange
>> >> > 2007
>> >> > on Windows Server 2008.  The backups would be done from the passive
>> >> > node
>> >> > of
>> >> > the CCR cluster.  I am trying to find some detailed documentation on
>> >> > how
>> >> > this
>> >> > is done so I can explain it to my backup and storage group.
>> >> >
>> >> > Does anyone know where I might find the documentation?
>> >>
>> >>
>> >>
>>
>>
>>

Is the snapshot local to the machine or can that be done somewhere else and 
then verified?

"John Fullbright" wrote:

> You verify the snapshot, yes.  The verification process reads each page of 
> the database and the header of each log file.  SME will archive the logs as 
> well so that you can do an up to the minute restore.  The archived logs are 
> moved to a subdirectory of the snapinfo directory specific to a given 
> snapshot, and the logs in your log lun are truncated.  If the snapinfo 
> directory is on the same lun as the logs, you can choose to use hard links 
> to archive log files.
> 
> If you have good connectivity between the datacenters, you may want to look 
> at using database portability in restore cases where you do not want to fail 
> the entire cluster over.  To use database portability, each SG in your must 
> be uniquely named.  Instead of using a convertion where server mail01 has 
> sg1, sg1, sg3, and mail02 has sg1, sg2, etc., use one like mail01_sg1, 
> mail01_sg2, mail02_sg1, etc..  This way, when you do a restore to alternate 
> server, the SG names don't conflict.  It doen't involve any additional 
> hardware or software, or for that matter cost anything to do this.  It does 
> leave your options open so that if you do find you want to restore a single 
> SG somewhere else, then you can.
> 
> 
> 
> "RJ"  wrote in message 
> news:449E80A0-3250-4A06-B7DE-AACE57C60652@microsoft.com...
> > We currently have a 1Gb connection between the two datacenters.
> >
> > So, the verification that is done is that performed on the snapped copy of
> > the database?  Is that then how Exchange knows that there was a valid 
> > backup
> > of the database and the logs can be purged and database marked as backed 
> > up?
> >
> > I apologize if these questions sound silly, but I am trying to understand
> > the VSS process.
> >
> > "John Fullbright" wrote:
> >
> >> Better is a relative term.  You need to define your requirement first.
> >> Depending on the requirement, either may work well for you.    If you 
> >> find
> >> you need more than a couple snapshots in place at any given time for a 
> >> given
> >> volume to meet your requirement, then the Netapp hardware VSS provider 
> >> has a
> >> clear performance advantage over the MS software provider used by DPM 
> >> which
> >> will impact your storage sizing.
> >>
> >> The online checksumming during maintenance process can be enabled, and 
> >> it's
> >> designed to checksum the active node when you do your backup and verify
> >> against the passive node.  With both DPM and Netapp's SME you have the
> >> option of deferring or not doing a verification.  I would go ahead and
> >> verify the passive copy even if you enable this feature.  I don't believe
> >> I've seen any guidance on using online maintenance checksumming instead 
> >> of a
> >> verify.  It seems to me to be a supplemental thing you can do to verify 
> >> the
> >> consitency of the active copy in addition to the eseutil verification of 
> >> the
> >> passive copy.  Perhaps Scott or someone else from MS could clarify here.
> >>
> >> For a CCR cluster, what does your connectivity look like between the 
> >> nodes?
> >> To fill the gap for a single database failure, you could do a restore to
> >> alternate server instead of failing the whole cluster over.  Exploitning
> >> database portability requires a little planning up front.  Each SG must 
> >> be
> >> uniquely named across your org.  I would factor this into your design to 
> >> at
> >> least leave that option open.  SME supports restoring to an alternate
> >> server.  SME can also restore to the passive node (it fails the cluster 
> >> over
> >> first because there is no Exchange VSS writer support for restore to a
> >> passive node).
> >>
> >> There's no scripting involved in verifying a backup with SME 4.X.  Netapp
> >> does follows 822896 as required by MS, but the application handles this 
> >> when
> >> you check the box to verify a backup.  If you backup with SME and have
> >> snapmirrored the LUNs to another storage device, you can verify againt 
> >> the
> >> snapmirror target as well.  You can verify on the host, or specify a 
> >> remote
> >> verification server to attach to the snapshots and run the verification.
> >> With DPM you can verify locally or specify a remote server to do the
> >> verification as well.  The only scripting for SME involves commands you
> >> would run after a backup; like snapvaulting to secondary storage or 
> >> updating
> >> a snapmirrored volume after the snapshot.
> >>
> >>
> >> John
> >>
> >> "RJ"  wrote in message
> >> news:A7068E6E-FDFA-4431-A9AA-55D6EC1A3AFF@microsoft.com...
> >> > John,
> >> >
> >> > Thanks for this valuable information.  We were planning on performing 
> >> > the
> >> > backups on the passive node to prevent creating a load on the active 
> >> > node.
> >> > This would be an issue for a restore as all users on the server would 
> >> > be
> >> > affected during the restore process.
> >> >
> >> > I believe we currently have Netapp.  I am trying to determine whether 
> >> > that
> >> > is a better solution than DPM.  I have concerns about the scripting 
> >> > that
> >> > is
> >> > involved with Netapp and verifying that we have a good backup.
> >> >
> >> > I came across an article yesterday that states there is new 
> >> > functionality
> >> > available in Exchange 2007 SP1 that checks the active database using a
> >> > utility called Online Maintenance Checksumming.
> >> > http://msexchangeteam.com/archive/2007/12/06/447695.aspx
> >> >
> >> > What do you think?
> >> >
> >> > "John Fullbright" wrote:
> >> >
> >> >> There are three parts to a VSS backup solution; the writer, the
> >> >> requestor,
> >> >> and the provider.  The writer is built into the application, Exchange.
> >> >> The
> >> >> provider is the piece that actually takes the snapshot.  You're 
> >> >> problably
> >> >> familiar with the Microsoft Software Provider.  SAN vendors typically
> >> >> provide a hardware provider for their SAN platform.
> >> >>
> >> >> Many providers are Copy on Write; when a snapshot is in place,
> >> >> overwriting
> >> >> involves copying the block out, writing it to a "difference area" and
> >> >> then
> >> >> overwriting the original data.  The space required for the snapshot is
> >> >> equal
> >> >> to the change delta between snapshots, and the performance hit is 3X 
> >> >> for
> >> >> overwrites.   Another type of provider is the clone.  It copies out 
> >> >> the
> >> >> whole volume on each snapshot.  The space consumes by a backup is 
> >> >> equal
> >> >> to
> >> >> the size of the volume.  Yet another kind of provider is Allocate on
> >> >> Write.
> >> >> For this type of provider, space consumed is equal to the change delta
> >> >> like
> >> >> copy on write, but there is no performance penalty.  Writes always 
> >> >> occur
> >> >> to
> >> >> free space, and a snapshot in place simply prevents the deallocation 
> >> >> or
> >> >> freeing of blocks.  In short, not all providers are created equal, 
> >> >> check
> >> >> with your vendor.
> >> >>
> >> >> The requestor is the piece you would probably recognize as "backup
> >> >> software"
> >> >> it coordinates the backup between the writer and the provider, 
> >> >> ensuring
> >> >> that
> >> >> IO is quiesced before the provider takes the snapshot and thawed
> >> >> afterwards
> >> >> so that the backup is consistent.  Verification per kb 822896 is 
> >> >> usually
> >> >> handled by the backup software as well.  This typically involves 
> >> >> invoking
> >> >> eseutil /k /i.  The verification of the VSS backup reads every page of
> >> >> the
> >> >> database and generates a lot of IO.  This is something to be aware of 
> >> >> and
> >> >> plan for when you do your sizing.  For copy on write and allocate on
> >> >> write
> >> >> snapshots a number of blacks are shared between the snapshot and the
> >> >> production LUN, so it can impact production if you're not careful.
> >> >>
> >> >> Given the above, it's understandable that COW based snapshot backups 
> >> >> like
> >> >> those provided by DPM aren't run that often; once a day or monce a 
> >> >> week.
> >> >> To
> >> >> attain a low RPO, DPM leverages incremental backups of the logs.
> >> >> Contrast
> >> >> that to an AOW snapshot like those created with the Netapp hardware
> >> >> provider
> >> >> which are typically run 4 to 8 times a day and can also supplement 
> >> >> that
> >> >> with
> >> >> incremental copies of the logs.  With COW, you don't want to leave 
> >> >> many
> >> >> snapshots in place; just a few and only long enough to copy them off 
> >> >> to a
> >> >> secondary storage device or tape.  For AOW, you can have 250 snaps in
> >> >> place
> >> >> with negligable performance degradation.  Although either can reach an
> >> >> RPO
> >> >> of 15 minutes (as low as 5 for Netapp actually), the restore 
> >> >> strategies
> >> >> and
> >> >> RTO can be quite different.  This is a function of how many snaps you 
> >> >> can
> >> >> have in place.
> >> >>
> >> >> While we're on the subject of restores, you mentioned CCR.  The 
> >> >> Exchange
> >> >> 2007 VSS writer does not support restore to the passive node.  If you
> >> >> take
> >> >> your backups from the passive node, then in order to restore even a
> >> >> single
> >> >> database you have to fail over  first.  That could painful.  Yes you 
> >> >> do
> >> >> take
> >> >> the load of verification off the primary storage, but you magnify the
> >> >> impact
> >> >> of single store corruption.  It's an all or nothing thing.  If you 
> >> >> have
> >> >> 50
> >> >> stores with 100 users per store, instead of impacting 100 users a 
> >> >> single
> >> >> store corruption impacts 5000 users.  Fortuately you have the option 
> >> >> of
> >> >> leveraging database prtability and restoring to an alternate server. 
> >> >> If
> >> >> all
> >> >> your clients are OL2K7, not a problem.  If they are downlevel outlook,
> >> >> you'll need to muck around with profiles (more likely distribute a prf
> >> >> file
> >> >> that modifies the  mailserver).  You'll need to examine the pros and 
> >> >> cons
> >> >> here as well to determine what best fits your needs.
> >> >>
> >> >> John
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> "RJ"  wrote in message
> >> >> news:12D99902-70E4-40CA-B4BB-0DD6E2B1109B@microsoft.com...
> >> >> > We are looking at using a VSS aware solution to do backups on 
> >> >> > Exchange
> >> >> > 2007
> >> >> > on Windows Server 2008.  The backups would be done from the passive
> >> >> > node
> >> >> > of
> >> >> > the CCR cluster.  I am trying to find some detailed documentation on
> >> >> > how
> >> >> > this
> >> >> > is done so I can explain it to my backup and storage group.
> >> >> >
> >> >> > Does anyone know where I might find the documentation?
> >> >>
> >> >>
> >> >>
> >>
> >>
> >> 
> 
> 
>

A snapshot exists on the same volume as the backing LUN.  The snapshot and 
the backing lun share a number of blocks.  You can present the snapshot to 
the host on which the snapshot was taken and verify there, or present the 
snapshot to another host and verify on another host (remote verification). 
If you are mirroring the volume to seconday storage, the verification host 
(local or remote) can connect to the snapmirror target an verify that (in 
this case there are no shared blocks with production).  If you're vaulting 
with snapvault (a tape replacement D2D backup technology), you can flexclone 
the the snapvault target and verify there as well from eithr a local or 
remote verification host.  The last two options (verification against 
snapmirror or snapvault targets) operate agains a replicated copy and do not 
touch blocks used by production.







"RJ"  wrote in message 
news:FC7C7E52-B6E2-4118-BD5E-A8F7DF5A7D66@microsoft.com...
> Is the snapshot local to the machine or can that be done somewhere else 
> and
> then verified?
>
> "John Fullbright" wrote:
>
>> You verify the snapshot, yes.  The verification process reads each page 
>> of
>> the database and the header of each log file.  SME will archive the logs 
>> as
>> well so that you can do an up to the minute restore.  The archived logs 
>> are
>> moved to a subdirectory of the snapinfo directory specific to a given
>> snapshot, and the logs in your log lun are truncated.  If the snapinfo
>> directory is on the same lun as the logs, you can choose to use hard 
>> links
>> to archive log files.
>>
>> If you have good connectivity between the datacenters, you may want to 
>> look
>> at using database portability in restore cases where you do not want to 
>> fail
>> the entire cluster over.  To use database portability, each SG in your 
>> must
>> be uniquely named.  Instead of using a convertion where server mail01 has
>> sg1, sg1, sg3, and mail02 has sg1, sg2, etc., use one like mail01_sg1,
>> mail01_sg2, mail02_sg1, etc..  This way, when you do a restore to 
>> alternate
>> server, the SG names don't conflict.  It doen't involve any additional
>> hardware or software, or for that matter cost anything to do this.  It 
>> does
>> leave your options open so that if you do find you want to restore a 
>> single
>> SG somewhere else, then you can.
>>
>>
>>
>> "RJ"  wrote in message
>> news:449E80A0-3250-4A06-B7DE-AACE57C60652@microsoft.com...
>> > We currently have a 1Gb connection between the two datacenters.
>> >
>> > So, the verification that is done is that performed on the snapped copy 
>> > of
>> > the database?  Is that then how Exchange knows that there was a valid
>> > backup
>> > of the database and the logs can be purged and database marked as 
>> > backed
>> > up?
>> >
>> > I apologize if these questions sound silly, but I am trying to 
>> > understand
>> > the VSS process.
>> >
>> > "John Fullbright" wrote:
>> >
>> >> Better is a relative term.  You need to define your requirement first.
>> >> Depending on the requirement, either may work well for you.    If you
>> >> find
>> >> you need more than a couple snapshots in place at any given time for a
>> >> given
>> >> volume to meet your requirement, then the Netapp hardware VSS provider
>> >> has a
>> >> clear performance advantage over the MS software provider used by DPM
>> >> which
>> >> will impact your storage sizing.
>> >>
>> >> The online checksumming during maintenance process can be enabled, and
>> >> it's
>> >> designed to checksum the active node when you do your backup and 
>> >> verify
>> >> against the passive node.  With both DPM and Netapp's SME you have the
>> >> option of deferring or not doing a verification.  I would go ahead and
>> >> verify the passive copy even if you enable this feature.  I don't 
>> >> believe
>> >> I've seen any guidance on using online maintenance checksumming 
>> >> instead
>> >> of a
>> >> verify.  It seems to me to be a supplemental thing you can do to 
>> >> verify
>> >> the
>> >> consitency of the active copy in addition to the eseutil verification 
>> >> of
>> >> the
>> >> passive copy.  Perhaps Scott or someone else from MS could clarify 
>> >> here.
>> >>
>> >> For a CCR cluster, what does your connectivity look like between the
>> >> nodes?
>> >> To fill the gap for a single database failure, you could do a restore 
>> >> to
>> >> alternate server instead of failing the whole cluster over. 
>> >> Exploitning
>> >> database portability requires a little planning up front.  Each SG 
>> >> must
>> >> be
>> >> uniquely named across your org.  I would factor this into your design 
>> >> to
>> >> at
>> >> least leave that option open.  SME supports restoring to an alternate
>> >> server.  SME can also restore to the passive node (it fails the 
>> >> cluster
>> >> over
>> >> first because there is no Exchange VSS writer support for restore to a
>> >> passive node).
>> >>
>> >> There's no scripting involved in verifying a backup with SME 4.X. 
>> >> Netapp
>> >> does follows 822896 as required by MS, but the application handles 
>> >> this
>> >> when
>> >> you check the box to verify a backup.  If you backup with SME and have
>> >> snapmirrored the LUNs to another storage device, you can verify againt
>> >> the
>> >> snapmirror target as well.  You can verify on the host, or specify a
>> >> remote
>> >> verification server to attach to the snapshots and run the 
>> >> verification.
>> >> With DPM you can verify locally or specify a remote server to do the
>> >> verification as well.  The only scripting for SME involves commands 
>> >> you
>> >> would run after a backup; like snapvaulting to secondary storage or
>> >> updating
>> >> a snapmirrored volume after the snapshot.
>> >>
>> >>
>> >> John
>> >>
>> >> "RJ"  wrote in message
>> >> news:A7068E6E-FDFA-4431-A9AA-55D6EC1A3AFF@microsoft.com...
>> >> > John,
>> >> >
>> >> > Thanks for this valuable information.  We were planning on 
>> >> > performing
>> >> > the
>> >> > backups on the passive node to prevent creating a load on the active
>> >> > node.
>> >> > This would be an issue for a restore as all users on the server 
>> >> > would
>> >> > be
>> >> > affected during the restore process.
>> >> >
>> >> > I believe we currently have Netapp.  I am trying to determine 
>> >> > whether
>> >> > that
>> >> > is a better solution than DPM.  I have concerns about the scripting
>> >> > that
>> >> > is
>> >> > involved with Netapp and verifying that we have a good backup.
>> >> >
>> >> > I came across an article yesterday that states there is new
>> >> > functionality
>> >> > available in Exchange 2007 SP1 that checks the active database using 
>> >> > a
>> >> > utility called Online Maintenance Checksumming.
>> >> > http://msexchangeteam.com/archive/2007/12/06/447695.aspx
>> >> >
>> >> > What do you think?
>> >> >
>> >> > "John Fullbright" wrote:
>> >> >
>> >> >> There are three parts to a VSS backup solution; the writer, the
>> >> >> requestor,
>> >> >> and the provider.  The writer is built into the application, 
>> >> >> Exchange.
>> >> >> The
>> >> >> provider is the piece that actually takes the snapshot.  You're
>> >> >> problably
>> >> >> familiar with the Microsoft Software Provider.  SAN vendors 
>> >> >> typically
>> >> >> provide a hardware provider for their SAN platform.
>> >> >>
>> >> >> Many providers are Copy on Write; when a snapshot is in place,
>> >> >> overwriting
>> >> >> involves copying the block out, writing it to a "difference area" 
>> >> >> and
>> >> >> then
>> >> >> overwriting the original data.  The space required for the snapshot 
>> >> >> is
>> >> >> equal
>> >> >> to the change delta between snapshots, and the performance hit is 
>> >> >> 3X
>> >> >> for
>> >> >> overwrites.   Another type of provider is the clone.  It copies out
>> >> >> the
>> >> >> whole volume on each snapshot.  The space consumes by a backup is
>> >> >> equal
>> >> >> to
>> >> >> the size of the volume.  Yet another kind of provider is Allocate 
>> >> >> on
>> >> >> Write.
>> >> >> For this type of provider, space consumed is equal to the change 
>> >> >> delta
>> >> >> like
>> >> >> copy on write, but there is no performance penalty.  Writes always
>> >> >> occur
>> >> >> to
>> >> >> free space, and a snapshot in place simply prevents the 
>> >> >> deallocation
>> >> >> or
>> >> >> freeing of blocks.  In short, not all providers are created equal,
>> >> >> check
>> >> >> with your vendor.
>> >> >>
>> >> >> The requestor is the piece you would probably recognize as "backup
>> >> >> software"
>> >> >> it coordinates the backup between the writer and the provider,
>> >> >> ensuring
>> >> >> that
>> >> >> IO is quiesced before the provider takes the snapshot and thawed
>> >> >> afterwards
>> >> >> so that the backup is consistent.  Verification per kb 822896 is
>> >> >> usually
>> >> >> handled by the backup software as well.  This typically involves
>> >> >> invoking
>> >> >> eseutil /k /i.  The verification of the VSS backup reads every page 
>> >> >> of
>> >> >> the
>> >> >> database and generates a lot of IO.  This is something to be aware 
>> >> >> of
>> >> >> and
>> >> >> plan for when you do your sizing.  For copy on write and allocate 
>> >> >> on
>> >> >> write
>> >> >> snapshots a number of blacks are shared between the snapshot and 
>> >> >> the
>> >> >> production LUN, so it can impact production if you're not careful.
>> >> >>
>> >> >> Given the above, it's understandable that COW based snapshot 
>> >> >> backups
>> >> >> like
>> >> >> those provided by DPM aren't run that often; once a day or monce a
>> >> >> week.
>> >> >> To
>> >> >> attain a low RPO, DPM leverages incremental backups of the logs.
>> >> >> Contrast
>> >> >> that to an AOW snapshot like those created with the Netapp hardware
>> >> >> provider
>> >> >> which are typically run 4 to 8 times a day and can also supplement
>> >> >> that
>> >> >> with
>> >> >> incremental copies of the logs.  With COW, you don't want to leave
>> >> >> many
>> >> >> snapshots in place; just a few and only long enough to copy them 
>> >> >> off
>> >> >> to a
>> >> >> secondary storage device or tape.  For AOW, you can have 250 snaps 
>> >> >> in
>> >> >> place
>> >> >> with negligable performance degradation.  Although either can reach 
>> >> >> an
>> >> >> RPO
>> >> >> of 15 minutes (as low as 5 for Netapp actually), the restore
>> >> >> strategies
>> >> >> and
>> >> >> RTO can be quite different.  This is a function of how many snaps 
>> >> >> you
>> >> >> can
>> >> >> have in place.
>> >> >>
>> >> >> While we're on the subject of restores, you mentioned CCR.  The
>> >> >> Exchange
>> >> >> 2007 VSS writer does not support restore to the passive node.  If 
>> >> >> you
>> >> >> take
>> >> >> your backups from the passive node, then in order to restore even a
>> >> >> single
>> >> >> database you have to fail over  first.  That could painful.  Yes 
>> >> >> you
>> >> >> do
>> >> >> take
>> >> >> the load of verification off the primary storage, but you magnify 
>> >> >> the
>> >> >> impact
>> >> >> of single store corruption.  It's an all or nothing thing.  If you
>> >> >> have
>> >> >> 50
>> >> >> stores with 100 users per store, instead of impacting 100 users a
>> >> >> single
>> >> >> store corruption impacts 5000 users.  Fortuately you have the 
>> >> >> option
>> >> >> of
>> >> >> leveraging database prtability and restoring to an alternate 
>> >> >> server.
>> >> >> If
>> >> >> all
>> >> >> your clients are OL2K7, not a problem.  If they are downlevel 
>> >> >> outlook,
>> >> >> you'll need to muck around with profiles (more likely distribute a 
>> >> >> prf
>> >> >> file
>> >> >> that modifies the  mailserver).  You'll need to examine the pros 
>> >> >> and
>> >> >> cons
>> >> >> here as well to determine what best fits your needs.
>> >> >>
>> >> >> John
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> "RJ"  wrote in message
>> >> >> news:12D99902-70E4-40CA-B4BB-0DD6E2B1109B@microsoft.com...
>> >> >> > We are looking at using a VSS aware solution to do backups on
>> >> >> > Exchange
>> >> >> > 2007
>> >> >> > on Windows Server 2008.  The backups would be done from the 
>> >> >> > passive
>> >> >> > node
>> >> >> > of
>> >> >> > the CCR cluster.  I am trying to find some detailed documentation 
>> >> >> > on
>> >> >> > how
>> >> >> > this
>> >> >> > is done so I can explain it to my backup and storage group.
>> >> >> >
>> >> >> > Does anyone know where I might find the documentation?
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>
>>
>>

In a previous post you wrote that I should refer to KB article 822896.  Is 
there a newer article for Exchange 2007 and Windows server 2008?

"John Fullbright" wrote:

> A snapshot exists on the same volume as the backing LUN.  The snapshot and 
> the backing lun share a number of blocks.  You can present the snapshot to 
> the host on which the snapshot was taken and verify there, or present the 
> snapshot to another host and verify on another host (remote verification). 
> If you are mirroring the volume to seconday storage, the verification host 
> (local or remote) can connect to the snapmirror target an verify that (in 
> this case there are no shared blocks with production).  If you're vaulting 
> with snapvault (a tape replacement D2D backup technology), you can flexclone 
> the the snapvault target and verify there as well from eithr a local or 
> remote verification host.  The last two options (verification against 
> snapmirror or snapvault targets) operate agains a replicated copy and do not 
> touch blocks used by production.
> 
> 
> 
> 
> 
> 
> 
> "RJ"  wrote in message 
> news:FC7C7E52-B6E2-4118-BD5E-A8F7DF5A7D66@microsoft.com...
> > Is the snapshot local to the machine or can that be done somewhere else 
> > and
> > then verified?
> >
> > "John Fullbright" wrote:
> >
> >> You verify the snapshot, yes.  The verification process reads each page 
> >> of
> >> the database and the header of each log file.  SME will archive the logs 
> >> as
> >> well so that you can do an up to the minute restore.  The archived logs 
> >> are
> >> moved to a subdirectory of the snapinfo directory specific to a given
> >> snapshot, and the logs in your log lun are truncated.  If the snapinfo
> >> directory is on the same lun as the logs, you can choose to use hard 
> >> links
> >> to archive log files.
> >>
> >> If you have good connectivity between the datacenters, you may want to 
> >> look
> >> at using database portability in restore cases where you do not want to 
> >> fail
> >> the entire cluster over.  To use database portability, each SG in your 
> >> must
> >> be uniquely named.  Instead of using a convertion where server mail01 has
> >> sg1, sg1, sg3, and mail02 has sg1, sg2, etc., use one like mail01_sg1,
> >> mail01_sg2, mail02_sg1, etc..  This way, when you do a restore to 
> >> alternate
> >> server, the SG names don't conflict.  It doen't involve any additional
> >> hardware or software, or for that matter cost anything to do this.  It 
> >> does
> >> leave your options open so that if you do find you want to restore a 
> >> single
> >> SG somewhere else, then you can.
> >>
> >>
> >>
> >> "RJ"  wrote in message
> >> news:449E80A0-3250-4A06-B7DE-AACE57C60652@microsoft.com...
> >> > We currently have a 1Gb connection between the two datacenters.
> >> >
> >> > So, the verification that is done is that performed on the snapped copy 
> >> > of
> >> > the database?  Is that then how Exchange knows that there was a valid
> >> > backup
> >> > of the database and the logs can be purged and database marked as 
> >> > backed
> >> > up?
> >> >
> >> > I apologize if these questions sound silly, but I am trying to 
> >> > understand
> >> > the VSS process.
> >> >
> >> > "John Fullbright" wrote:
> >> >
> >> >> Better is a relative term.  You need to define your requirement first.
> >> >> Depending on the requirement, either may work well for you.    If you
> >> >> find
> >> >> you need more than a couple snapshots in place at any given time for a
> >> >> given
> >> >> volume to meet your requirement, then the Netapp hardware VSS provider
> >> >> has a
> >> >> clear performance advantage over the MS software provider used by DPM
> >> >> which
> >> >> will impact your storage sizing.
> >> >>
> >> >> The online checksumming during maintenance process can be enabled, and
> >> >> it's
> >> >> designed to checksum the active node when you do your backup and 
> >> >> verify
> >> >> against the passive node.  With both DPM and Netapp's SME you have the
> >> >> option of deferring or not doing a verification.  I would go ahead and
> >> >> verify the passive copy even if you enable this feature.  I don't 
> >> >> believe
> >> >> I've seen any guidance on using online maintenance checksumming 
> >> >> instead
> >> >> of a
> >> >> verify.  It seems to me to be a supplemental thing you can do to 
> >> >> verify
> >> >> the
> >> >> consitency of the active copy in addition to the eseutil verification 
> >> >> of
> >> >> the
> >> >> passive copy.  Perhaps Scott or someone else from MS could clarify 
> >> >> here.
> >> >>
> >> >> For a CCR cluster, what does your connectivity look like between the
> >> >> nodes?
> >> >> To fill the gap for a single database failure, you could do a restore 
> >> >> to
> >> >> alternate server instead of failing the whole cluster over. 
> >> >> Exploitning
> >> >> database portability requires a little planning up front.  Each SG 
> >> >> must
> >> >> be
> >> >> uniquely named across your org.  I would factor this into your design 
> >> >> to
> >> >> at
> >> >> least leave that option open.  SME supports restoring to an alternate
> >> >> server.  SME can also restore to the passive node (it fails the 
> >> >> cluster
> >> >> over
> >> >> first because there is no Exchange VSS writer support for restore to a
> >> >> passive node).
> >> >>
> >> >> There's no scripting involved in verifying a backup with SME 4.X. 
> >> >> Netapp
> >> >> does follows 822896 as required by MS, but the application handles 
> >> >> this
> >> >> when
> >> >> you check the box to verify a backup.  If you backup with SME and have
> >> >> snapmirrored the LUNs to another storage device, you can verify againt
> >> >> the
> >> >> snapmirror target as well.  You can verify on the host, or specify a
> >> >> remote
> >> >> verification server to attach to the snapshots and run the 
> >> >> verification.
> >> >> With DPM you can verify locally or specify a remote server to do the
> >> >> verification as well.  The only scripting for SME involves commands 
> >> >> you
> >> >> would run after a backup; like snapvaulting to secondary storage or
> >> >> updating
> >> >> a snapmirrored volume after the snapshot.
> >> >>
> >> >>
> >> >> John
> >> >>
> >> >> "RJ"  wrote in message
> >> >> news:A7068E6E-FDFA-4431-A9AA-55D6EC1A3AFF@microsoft.com...
> >> >> > John,
> >> >> >
> >> >> > Thanks for this valuable information.  We were planning on 
> >> >> > performing
> >> >> > the
> >> >> > backups on the passive node to prevent creating a load on the active
> >> >> > node.
> >> >> > This would be an issue for a restore as all users on the server 
> >> >> > would
> >> >> > be
> >> >> > affected during the restore process.
> >> >> >
> >> >> > I believe we currently have Netapp.  I am trying to determine 
> >> >> > whether
> >> >> > that
> >> >> > is a better solution than DPM.  I have concerns about the scripting
> >> >> > that
> >> >> > is
> >> >> > involved with Netapp and verifying that we have a good backup.
> >> >> >
> >> >> > I came across an article yesterday that states there is new
> >> >> > functionality
> >> >> > available in Exchange 2007 SP1 that checks the active database using 
> >> >> > a
> >> >> > utility called Online Maintenance Checksumming.
> >> >> > http://msexchangeteam.com/archive/2007/12/06/447695.aspx
> >> >> >
> >> >> > What do you think?
> >> >> >
> >> >> > "John Fullbright" wrote:
> >> >> >
> >> >> >> There are three parts to a VSS backup solution; the writer, the
> >> >> >> requestor,
> >> >> >> and the provider.  The writer is built into the application, 
> >> >> >> Exchange.
> >> >> >> The
> >> >> >> provider is the piece that actually takes the snapshot.  You're
> >> >> >> problably
> >> >> >> familiar with the Microsoft Software Provider.  SAN vendors 
> >> >> >> typically
> >> >> >> provide a hardware provider for their SAN platform.
> >> >> >>
> >> >> >> Many providers are Copy on Write; when a snapshot is in place,
> >> >> >> overwriting
> >> >> >> involves copying the block out, writing it to a "difference area" 
> >> >> >> and
> >> >> >> then
> >> >> >> overwriting the original data.  The space required for the snapshot 
> >> >> >> is
> >> >> >> equal
> >> >> >> to the change delta between snapshots, and the performance hit is 
> >> >> >> 3X
> >> >> >> for
> >> >> >> overwrites.   Another type of provider is the clone.  It copies out
> >> >> >> the
> >> >> >> whole volume on each snapshot.  The space consumes by a backup is
> >> >> >> equal
> >> >> >> to
> >> >> >> the size of the volume.  Yet another kind of provider is Allocate 
> >> >> >> on
> >> >> >> Write.
> >> >> >> For this type of provider, space consumed is equal to the change 
> >> >> >> delta
> >> >> >> like
> >> >> >> copy on write, but there is no performance penalty.  Writes always
> >> >> >> occur
> >> >> >> to
> >> >> >> free space, and a snapshot in place simply prevents the 
> >> >> >> deallocation
> >> >> >> or
> >> >> >> freeing of blocks.  In short, not all providers are created equal,
> >> >> >> check
> >> >> >> with your vendor.
> >> >> >>
> >> >> >> The requestor is the piece you would probably recognize as "backup
> >> >> >> software"
> >> >> >> it coordinates the backup between the writer and the provider,
> >> >> >> ensuring
> >> >> >> that
> >> >> >> IO is quiesced before the provider takes the snapshot and thawed
> >> >> >> afterwards
> >> >> >> so that the backup is consistent.  Verification per kb 822896 is
> >> >> >> usually
> >> >> >> handled by the backup software as well.  This typically involves
> >> >> >> invoking
> >> >> >> eseutil /k /i.  The verification of the VSS backup reads every page 
> >> >> >> of
> >> >> >> the
> >> >> >> database and generates a lot of IO.  This is something to be aware 
> >> >> >> of
> >> >> >> and
> >> >> >> plan for when you do your sizing.  For copy on write and allocate 
> >> >> >> on
> >> >> >> write
> >> >> >> snapshots a number of blacks are shared between the snapshot and 
> >> >> >> the
> >> >> >> production LUN, so it can impact production if you're not careful.
> >> >> >>
> >> >> >> Given the above, it's understandable that COW based snapshot 
> >> >> >> backups
> >> >> >> like
> >> >> >> those provided by DPM aren't run that often; once a day or monce a
> >> >> >> week.
> >> >> >> To
> >> >> >> attain a low RPO, DPM leverages incremental backups of the logs.
> >> >> >> Contrast
> >> >> >> that to an AOW snapshot like those created with the Netapp hardware
> >> >> >> provider
> >> >> >> which are typically run 4 to 8 times a day and can also supplement
> >> >> >> that
> >> >> >> with
> >> >> >> incremental copies of the logs.  With COW, you don't want to leave
> >> >> >> many
> >> >> >> snapshots in place; just a few and only long enough to copy them 
> >> >> >> off
> >> >> >> to a
> >> >> >> secondary storage device or tape.  For AOW, you can have 250 snaps 
> >> >> >> in
> >> >> >> place
> >> >> >> with negligable performance degradation.  Although either can reach 
> >> >> >> an
> >> >> >> RPO
> >> >> >> of 15 minutes (as low as 5 for Netapp actually), the restore
> >> >> >> strategies
> >> >> >> and
> >> >> >> RTO can be quite different.  This is a function of how many snaps 
> >> >> >> you
> >> >> >> can
> >> >> >> have in place.
> >> >> >>
> >> >> >> While we're on the subject of restores, you mentioned CCR.  The
> >> >> >> Exchange
> >> >> >> 2007 VSS writer does not support restore to the passive node.  If 
> >> >> >> you
> >> >> >> take
> >> >> >> your backups from the passive node, then in order to restore even a
> >> >> >> single
> >> >> >> database you have to fail over  first.  That could painful.  Yes 
> >> >> >> you
> >> >> >> do
> >> >> >> take
> >> >> >> the load of verification off the primary storage, but you magnify 
> >> >> >> the
> >> >> >> impact
> >> >> >> of single store corruption.  It's an all or nothing thing.  If you
> >> >> >> have
> >> >> >> 50
> >> >> >> stores with 100 users per store, instead of impacting 100 users a
> >> >> >> single
> >> >> >> store corruption impacts 5000 users.  Fortuately you have the

It's the same, the article needs to be updated.


"RJ"  wrote in message 
news:5C8AD32D-6FC9-4C8B-815D-F0BFFBA7459E@microsoft.com...
> In a previous post you wrote that I should refer to KB article 822896.  Is
> there a newer article for Exchange 2007 and Windows server 2008?
>
> "John Fullbright" wrote:
>
>> A snapshot exists on the same volume as the backing LUN.  The snapshot 
>> and
>> the backing lun share a number of blocks.  You can present the snapshot 
>> to
>> the host on which the snapshot was taken and verify there, or present the
>> snapshot to another host and verify on another host (remote 
>> verification).
>> If you are mirroring the volume to seconday storage, the verification 
>> host
>> (local or remote) can connect to the snapmirror target an verify that (in
>> this case there are no shared blocks with production).  If you're 
>> vaulting
>> with snapvault (a tape replacement D2D backup technology), you can 
>> flexclone
>> the the snapvault target and verify there as well from eithr a local or
>> remote verification host.  The last two options (verification against
>> snapmirror or snapvault targets) operate agains a replicated copy and do 
>> not
>> touch blocks used by production.
>>
>>
>>
>>
>>
>>
>>
>> "RJ"  wrote in message
>> news:FC7C7E52-B6E2-4118-BD5E-A8F7DF5A7D66@microsoft.com...
>> > Is the snapshot local to the machine or can that be done somewhere else
>> > and
>> > then verified?
>> >
>> > "John Fullbright" wrote:
>> >
>> >> You verify the snapshot, yes.  The verification process reads each 
>> >> page
>> >> of
>> >> the database and the header of each log file.  SME will archive the 
>> >> logs
>> >> as
>> >> well so that you can do an up to the minute restore.  The archived 
>> >> logs
>> >> are
>> >> moved to a subdirectory of the snapinfo directory specific to a given
>> >> snapshot, and the logs in your log lun are truncated.  If the snapinfo
>> >> directory is on the same lun as the logs, you can choose to use hard
>> >> links
>> >> to archive log files.
>> >>
>> >> If you have good connectivity between the datacenters, you may want to
>> >> look
>> >> at using database portability in restore cases where you do not want 
>> >> to
>> >> fail
>> >> the entire cluster over.  To use database portability, each SG in your
>> >> must
>> >> be uniquely named.  Instead of using a convertion where server mail01 
>> >> has
>> >> sg1, sg1, sg3, and mail02 has sg1, sg2, etc., use one like mail01_sg1,
>> >> mail01_sg2, mail02_sg1, etc..  This way, when you do a restore to
>> >> alternate
>> >> server, the SG names don't conflict.  It doen't involve any additional
>> >> hardware or software, or for that matter cost anything to do this.  It
>> >> does
>> >> leave your options open so that if you do find you want to restore a
>> >> single
>> >> SG somewhere else, then you can.
>> >>
>> >>
>> >>
>> >> "RJ"  wrote in message
>> >> news:449E80A0-3250-4A06-B7DE-AACE57C60652@microsoft.com...
>> >> > We currently have a 1Gb connection between the two datacenters.
>> >> >
>> >> > So, the verification that is done is that performed on the snapped 
>> >> > copy
>> >> > of
>> >> > the database?  Is that then how Exchange knows that there was a 
>> >> > valid
>> >> > backup
>> >> > of the database and the logs can be purged and database marked as
>> >> > backed
>> >> > up?
>> >> >
>> >> > I apologize if these questions sound silly, but I am trying to
>> >> > understand
>> >> > the VSS process.
>> >> >
>> >> > "John Fullbright" wrote:
>> >> >
>> >> >> Better is a relative term.  You need to define your requirement 
>> >> >> first.
>> >> >> Depending on the requirement, either may work well for you.    If 
>> >> >> you
>> >> >> find
>> >> >> you need more than a couple snapshots in place at any given time 
>> >> >> for a
>> >> >> given
>> >> >> volume to meet your requirement, then the Netapp hardware VSS 
>> >> >> provider
>> >> >> has a
>> >> >> clear performance advantage over the MS software provider used by 
>> >> >> DPM
>> >> >> which
>> >> >> will impact your storage sizing.
>> >> >>
>> >> >> The online checksumming during maintenance process can be enabled, 
>> >> >> and
>> >> >> it's
>> >> >> designed to checksum the active node when you do your backup and
>> >> >> verify
>> >> >> against the passive node.  With both DPM and Netapp's SME you have 
>> >> >> the
>> >> >> option of deferring or not doing a verification.  I would go ahead 
>> >> >> and
>> >> >> verify the passive copy even if you enable this feature.  I don't
>> >> >> believe
>> >> >> I've seen any guidance on using online maintenance checksumming
>> >> >> instead
>> >> >> of a
>> >> >> verify.  It seems to me to be a supplemental thing you can do to
>> >> >> verify
>> >> >> the
>> >> >> consitency of the active copy in addition to the eseutil 
>> >> >> verification
>> >> >> of
>> >> >> the
>> >> >> passive copy.  Perhaps Scott or someone else from MS could clarify
>> >> >> here.
>> >> >>
>> >> >> For a CCR cluster, what does your connectivity look like between 
>> >> >> the
>> >> >> nodes?
>> >> >> To fill the gap for a single database failure, you could do a 
>> >> >> restore
>> >> >> to
>> >> >> alternate server instead of failing the whole cluster over.
>> >> >> Exploitning
>> >> >> database portability requires a little planning up front.  Each SG
>> >> >> must
>> >> >> be
>> >> >> uniquely named across your org.  I would factor this into your 
>> >> >> design
>> >> >> to
>> >> >> at
>> >> >> least leave that option open.  SME supports restoring to an 
>> >> >> alternate
>> >> >> server.  SME can also restore to the passive node (it fails the
>> >> >> cluster
>> >> >> over
>> >> >> first because there is no Exchange VSS writer support for restore 
>> >> >> to a
>> >> >> passive node).
>> >> >>
>> >> >> There's no scripting involved in verifying a backup with SME 4.X.
>> >> >> Netapp
>> >> >> does follows 822896 as required by MS, but the application handles
>> >> >> this
>> >> >> when
>> >> >> you check the box to verify a backup.  If you backup with SME and 
>> >> >> have
>> >> >> snapmirrored the LUNs to another storage device, you can verify 
>> >> >> againt
>> >> >> the
>> >> >> snapmirror target as well.  You can verify on the host, or specify 
>> >> >> a
>> >> >> remote
>> >> >> verification server to attach to the snapshots and run the
>> >> >> verification.
>> >> >> With DPM you can verify locally or specify a remote server to do 
>> >> >> the
>> >> >> verification as well.  The only scripting for SME involves commands
>> >> >> you
>> >> >> would run after a backup; like snapvaulting to secondary storage or
>> >> >> updating
>> >> >> a snapmirrored volume after the snapshot.
>> >> >>
>> >> >>
>> >> >> John
>> >> >>
>> >> >> "RJ"  wrote in message
>> >> >> news:A7068E6E-FDFA-4431-A9AA-55D6EC1A3AFF@microsoft.com...
>> >> >> > John,
>> >> >> >
>> >> >> > Thanks for this valuable information.  We were planning on
>> >> >> > performing
>> >> >> > the
>> >> >> > backups on the passive node to prevent creating a load on the 
>> >> >> > active
>> >> >> > node.
>> >> >> > This would be an issue for a restore as all users on the server
>> >> >> > would
>> >> >> > be
>> >> >> > affected during the restore process.
>> >> >> >
>> >> >> > I believe we currently have Netapp.  I am trying to determine
>> >> >> > whether
>> >> >> > that
>> >> >> > is a better solution than DPM.  I have concerns about the 
>> >> >> > scripting
>> >> >> > that
>> >> >> > is
>> >> >> > involved with Netapp and verifying that we have a good backup.
>> >> >> >
>> >> >> > I came across an article yesterday that states there is new
>> >> >> > functionality
>> >> >> > available in Exchange 2007 SP1 that checks the active database 
>> >> >> > using
>> >> >> > a
>> >> >> > utility called Online Maintenance Checksumming.
>> >> >> > http://msexchangeteam.com/archive/2007/12/06/447695.aspx
>> >> >> >
>> >> >> > What do you think?
>> >> >> >
>> >> >> > "John Fullbright" wrote:
>> >> >> >
>> >> >> >> There are three parts to a VSS backup solution; the writer, the
>> >> >> >> requestor,
>> >> >> >> and the provider.  The writer is built into the application,
>> >> >> >> Exchange.
>> >> >> >> The
>> >> >> >> provider is the piece that actually takes the snapshot.  You're
>> >> >> >> problably
>> >> >> >> familiar with the Microsoft Software Provider.  SAN vendors
>> >> >> >> typically
>> >> >> >> provide a hardware provider for their SAN platform.
>> >> >> >>
>> >> >> >> Many providers are Copy on Write; when a snapshot is in place,
>> >> >> >> overwriting
>> >> >> >> involves copying the block out, writing it to a "difference 
>> >> >> >> area"
>> >> >> >> and
>> >> >> >> then
>> >> >> >> overwriting the original data.  The space required for the 
>> >> >> >> snapshot
>> >> >> >> is
>> >> >> >> equal
>> >> >> >> to the change delta between snapshots, and the performance hit 
>> >> >> >> is
>> >> >> >> 3X
>> >> >> >> for
>> >> >> >> overwrites.   Another type of provider is the clone.  It copies 
>> >> >> >> out
>> >> >> >> the
>> >> >> >> whole volume on each snapshot.  The space consumes by a backup 
>> >> >> >> is
>> >> >> >> equal
>> >> >> >> to
>> >> >> >> the size of the volume.  Yet another kind of provider is 
>> >> >> >> Allocate
>> >> >> >> on
>> >> >> >> Write.
>> >> >> >> For this type of provider, space consumed is equal to the change
>> >> >> >> delta
>> >> >> >> like
>> >> >> >> copy on write, but there is no performance penalty.  Writes 
>> >> >>