Exchange 2007 and Windows 2008: Using Diskshadow for Online Exchange Backup (part 5 of 7)

If you hadn’t noticed, I’ve been following a theme the last couple of months with some of the entries on this blog:

Part 1: Getting a List of Storage Groups in a PowerShell Script

Part 2: Getting a List of Stores in a PowerShell Script

Part 3: Exchange 2007 and Windows 2008: Offline Exchange Backup

Part 4: Volume Shadow Copy Services (VSS) and Exchange – The Basics

In this posting, which is part 5 of a 7-part series, I’ll talk about a command-line tool which is new for Windows Server 2008: Diskshadow. The entire purpose behind Diskshadow is to allow a system administrator to harness the power of VSS from an easy-to-use utility. This is not the first utility from Microsoft that uses VSS (BETest and VShadow were both part of the VSS Software Development Kit), but it is the first supported utility for using VSS.

Let me begin by displaying a Diskshadow input file, and then I’ll discuss it, line by line. In case it isn’t obvious, you do not include line numbers inside a Diskshadow input file. They are shown here just for discussion. Also, the typical extension used for a Diskshadow input file is DSH. So, you might call this file offline-backup.dsh.

1 # set verbose on
2 set context persistent
3 writer verify {76fe1ac4-15f7-4bcd-987e-8e1acb462fb7}
4 begin backup
5 add volume c: alias shadow_c
6 create
7 expose %shadow_c% g:
8 # exec offline-backup.cmd
9 end backup
10 delete shadows exposed g:
11 exit

Line 1 begins with a hash-mark. This is indicative of a comment to the Diskshadow utility. Anything that occurs after the hash-mark on this line is ignored. However, if the hash-mark were not present, the command “set verbose on” would cause Diskshadow to output additional information as it determines the writers and components that will be included within the shadow copy.

Line 2 indicates that the shadow copy which is created will be persistent – that is, the shadow copy will continue to exist after the “end backup” (line 9) statement is executed. Shadow copies must be persistent in order to expose them (line 7). It is much easier to work with a shadow copy exposed as a drive letter than to use native format shadow copy names. For example, a typical shadow copy may be named \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy25 with a GUID of {e18b18b2-c8dd-4429-9996-af8d582616d8}.

Line 3 causes Diskshadow to verify that the particular writer having the named GUID is present on this computer. This GUID is the specific ID for “Microsoft Exchange Writer”. This check effectively requires that this script is executed on an Exchange server. In order to see a list off all writers and their writer IDs, you can enter “vssadmin list writers” from a command prompt or within Diskshadow you can enter the “list writers” command. Note that you can also use the “writer exclude” command to ensure that a specific writer is not called as part of this backup.

Line 4 will start the actual VSS communication process by notifying all non-excluded writers to PrepareBackup. PrepareBackup was discussed in Volume Shadow Copy Services (VSS) and Exchange – The Basics.

Line 5 is used to identify a specific volume (could be a mount-point) that must be included in this VSS snapshot. You must identify all volumes that are involved in a backup. You learned how to do that for Exchange in Getting a List of Storage Groups in a PowerShell Script and Getting a List of Stores in a PowerShell Script.

Line 6 signals VSS to initiate Freeze and to create a snapshot. When the snapshot is complete, Diskshadow will signal VSS to Thaw. Freeze and Thaw were discussed in Volume Shadow Copy Services (VSS) and Exchange – The Basics.

Line 7 tells Diskshadow to expose the snapshot of a particular volume as a different drive letter (which may also be a mount point). This is primarily for ease-of-access, as I discussed for Line 2.

Line 8 is another comment. If it were not a comment, the EXEC command would cause Diskshadow to execute an external script. THAT SCRIPT is where a copy from a snapshot is actually created. You learned about how to generate that type of script in Exchange 2007 and Windows 2008: Offline Exchange Backup. If the script returns a non-zero value, then Diskshadow aborts.

Line 9 causes Diskshadow to signal VSS to send PostBackup to all involved writers. PostBackup was discussed in Volume Shadow Copy Services (VSS) and Exchange – The Basics.

Line 10 removes the snapshot associated with the drive letter G:, and deletes the drive mapping for G:. The storage space used by the snapshot is returned to the system.

Finally, line 11 terminates Diskshadow.

It is important to realize that after the CREATE statement finishes, what you have is a snapshot. It is not a backup, just a copy of the MFT and in-use bitmap for the disk drives that were included in the snapshot. You learned about the MFT and in-use bitmaps in Volume Shadow Copy Services (VSS) and Exchange – The Basics.

The script executed by line 8 is what creates copies of the files that are your actual backup.

You should also be aware that for any writer that was excluded from the backup, the files protected by that writer are still present in the snapshot; however they are CRASH CONSISTENT (i.e., in the same condition that would’ve happened if the power plug had been pulled on a server) not APPLICATION CONSISTENT (which is what you want for maximum recoverability).

In part 6 of this series, I will put all of the pieces together, and come up with a single PowerShell script that does “everything” to create an Exchange backup for you.

In part 7 of this series, I will cover doing simple restores of Exchange databases.

Until next time…

As always, if there are items you would like me to talk about, please drop me a line and let me know!

Follow me on twitter: @EssentialExch

Leave a Reply

Your email address will not be published. Required fields are marked *