In a previous blog post at https://blogs.technet.com/filecab/archive/2009/04/11/lun-resync-a-fast-recovery-scenario-in-server-2008-r2.aspx we described LUN Resync as a new fast recovery scenario supported with windows Server 2008 R2.

In this article well walk through some samples and in-box tools that can be used to exercise the scenario.

Following illustrations use VSS Sample Provider (vsssampleprovider.dll), Virtual Storage (VirtualStorage.sys) and the inbox requester 'DiskShadow'; both, the sample provider and virtual storage are provided in the latest Platform SDK.

Creating Virtual Storage Drive:

One can use Virtual Storage to emulate a storage array; the vstorcontrol utility from VSS SDK can be used to create and manage virtual drives for this virtual storage array.

For example, heres a command for creating a virtual LUN using the VirtualStorage driver. (VSSSampleProvider acts as the VSS HW Provider for these),

Vstorcontrol.exe create fixeddisk –newimage C:\diskone.img –size 45M –storid “VSS Sample HW Provider” I will come back to this storid later.

Heres a sample script to create a transportable shadow copy with no writers involved,

 

SET CONTEXT PERSISTENT NOWRITERS

SET OPTION TRANSPORTABLE

SET METADATA %DISKSH_PARAM_1%

ADD VOLUME %DISKSH_PARAM_2% ALIAS TESTSHADOW

CREATE

 

Diskshadow /s transportable.script %BCD% %TESTDRIVE% where %TESTDRIVE% is a drive on a virtual storage LUN.

 

Once we create a transportable shadow, it can be ReSynced to a target drive as below,

 

LOAD METADATA    %DISKSH_PARAM_1%

ADD SHADOW    %TESTSHADOW%    %DISKSH_PARAM_2%

RESYNC    [NOVOLCHECK]    [REVERT_ORIGINALSIG]

 

NOVOLCHECK and REVERT_ORIGINALSIG are optional parameters and are explained below.

Diskshadow /s resync.script %BCD% %TARGETDRIVE% where %TARGETDRIVE% is a drive on a virtual storage LUN that you want to resync to.

 

Requesters call AddSnapshotToRecoverySet for each pair of snapshot and the target LUN they want the snapshot to resync to. In the resync script above, we do the same in ADD SHADOW by specifying a shadow alias and a target drive. VSS gets the backup component document in the InitializeForRestore call as with any other restore sequence and in the absence of a target LUN parameter VSS would resync the shadow to the original LUN that it finds from the Backup Component Document.

Options for the Resync operation:

A Requester can specify a couple of flags for the resync operation through the RecoverSet call.

·         REVERT_ORIGINALSIG: Specifying VSS_RECOVERY_REVERT_IDENTITY_ALL for VSS_RECOVERY_OPTIONS during RecoverSet suggests the target LUN is expected to have the same disk signature as that of the snapshot LUN. We specify REVERT_ORIGINALSIG as a resync parameter above in the resync script to specify this choice through diskshadow.

 

§  disk signatures:

 

The MBR disk signature is a 32 bit identifier that begins at 0x1B8 (440) of the first sector of a MBR intialized disk.

For a GPT initialized disk, the disk identifier is the disk GUID saved in the GPT Header. The GUID starts at offset 56 into the partition table header with the first three GUID blocks byte-swapped (little endian), the actual GUID below being {99ba5d42-3609-4d28-beff-1bf7a25c3765}

 

Offset      0  1  2  3  4  5  6  7   8  9 10 11 12 13 14 15

00000496   00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 AA                

00000512   45 46 49 20 50 41 52 54  00 00 01 00 5C 00 00 00   EFI PART    \  

00000528   93 69 C5 5A 00 00 00 00  01 00 00 00 00 00 00 00   ôi┼Z           

00000544   FF 67 01 00 00 00 00 00  22 00 00 00 00 00 00 00    g      "      

00000560   DE 67 01 00 00 00 00 00  42 5D BA 99 09 36 28 4D   ▐g      B]║Ö 6(M

00000576   BE FF 1B F7 A2 5C 37 65  02 00 00 00 00 00 00 00   ╛  ≈ó\7e       

00000592   80 00 00 00 80 00 00 00  15 02 45 FC 00 00 00 00   Ç   Ç     Eⁿ   

 

§  No two disks on a system in an online state can have identical disk signatures, so VSS will not be able to change the disk signature of the target LUN if the original LUN is still present in the system and is in an online state. In this case VSS tries its best to bring the LUN in an operable online state and does so by leaving the target LUN signature as it is.

 

·         NOVOLCHECK: This diskshadow flag corresponds to VSS_RECOVERY_NO_VOLUME_CHECK of VSS_RECOVERY_OPTIONS during RecoverSet and helps protect one or more unselected volumes on the target LUN from being silently overwritten during a resync operation. Specifying this option would indicate that the operation need not do the above check and it is OK to overwrite all the drives on the target LUN. A VSS resync operation as in the above scenario will fail in absence of this flag.

Unique Identifiers Check during Resync:

In most of the VSS operations we use unique LUN identifiers i.e. page 80 and page 83 to identify LUNs on a system. Both of these LUN identifiers can be found out using IOCTL_STORAGE_QUERY_PROPERTY with STORAGE_PROPERTY_ID of STORAGE_PROPERTY_QUERY set to StorageDeviceProperty for page 80 and StorageDeviceIdProperty for page 83 identifiers. Adi has an interesting blog on LUN identifiers here.

LUN Resync specifically uses page 83 identifiers to uniquely identify LUNs as opposed to the VSS import scenarios which fall back onto page 80 identifiers if the array doesnt exhibit page 83 identifiers to VSS.

Virtual Storage Implements the Resync operation by swapping LUNs; while creating a transportable snapshot, VSS Sample Provider makes a copy of the snapshot LUNs backing store and while resyncing that snapshot to a target, swaps the targets backing store with yet another copy of the snapshot backing store we created earlier.

During this resync swap exercise, the virtual storage target LUN has the same page 83 identifiers before and after the resync.

Heres a snip for page 83 LUN identifiers for a Virtual Storage LUN (using the sample app from Adis blog).

Querying information for disk '\\.\PhysicalDrive5' ...

- Page83.NumberOfIdentifiers: 1

 

- Page83.Identifier

   - Type: 1

   - Association: 0

   - Size: 60

   - IsGloballyUnique? TRUE

   - Data:

 56 00 53 00 53 00 20 00 53 00 61 00 6d 00 70 00 6c 00 65 00 20 00 48 00 57 00 20 00 50 00 72 00 6f 00 76 00 69 00 64 00

 65 00 72 00 d6 28 a3 6a 7c 89 5b 43 ad 88 ae e3 6a bc 55 ff

If I dump the data bytes, I find the storid string I set earlier while creating the drive,

 V   S   S       S   a   m   p   l   e       H   W       P   r   o   v   i   d   e   r   ╓ ( ú j | ë [ C ¡ ê « π j ╝ U  

The Storid string, as I referred to earlier while creating a virtual drive, is the start of the first page 83 identifier that the virtual LUN gets created with. The Sample VSS Hardware Provider checks for this string in AreLunsSupported call to figure out the LUNs it is supposed to manage or support for VSS Snapshots.

The type of the identifier above is 1 which denotes a variable-length identifier in T10 standard identifier format. Identifier types 1, 2, 3 and 8 are unique identifiers and VSS uses one of these identifier types to uniquely identify a LUN.