Views:

Summary

The intent of this document is to guide you through the process of performing an Instant Access (IA) of a VMDK from an Agentless VMware Backup that expired through restoring the original volume that was backed up with the SnapMirror to Tape NDMP protocol (SMTape). Instant Access of an agentless backup is the ability to iSCSI-map a LUN to a server with iSCSI initiator. To perform a manual Instant Access from a SMTape backup, first restore the data from tape backup onto a NetApp storage system volume.

Step By Step

NDMP Restore

An NDMP restore is a process whereby data is restored from tape to a NetApp storage system. The NetApp storage system that you decide to restore to does not have to be identical to the one that you backed up from.

1) Create a new volume using NetApp OnCommand System Manager. Provide a volume name for the NDMP data to be restored to. Host the created volume on an aggregate with the available space to accommodate the restore. Thin provision the volume and the Total Size should be at least as large as the original volume size. As a best practice, make the volume incrementally larger by at least a few percent to avoid any buffer/block/bit size discrepancies that are not worth troubleshooting. Set the Snapshot Reserve to 0 and the Storage Type to SAN.

2) Prior to performing a restore, the new volume must be set to Restrict. Select the created volume and right-click Status > Restrict.

3) Login to the NSB management console and go to Restore > NDMP. Under the SOURCES pane, select the appropriate Device Cluster and expand the NetApp storage system. Select the NDMP backup to restore. Under the DESTINATIONS, select the newly created volume.

4) Save the job and run the Restore Job.

Tip: Click the Summary tab to monitor the progress of the NDMP restore.
After the NDMP restore is complete, the next step is to perform an IA of an agentless backup.

Instant Access from a NDMP Restore

Ensure that a NDMP restore is complete. If it is not, follow the steps in NDMP Restore before continuing.
Verify if the Microsoft iSCSI Initiator service is Started on the machine where the mapping will be performed.

Putty into the NetApp storage system where the data was restored to.

Prior to running the commands, ensure the advanced privileges are set on the filer using the following command:

priv set advanced

After the restore job is complete, the qtrees display from the NetApp storage systems command line. Each of these qtrees represents a VM that was backed up. In our scenario, there are two VMs which were backed up using agentless.

The following command is used to display the restored qtrees in the volume where the NDMP data was restored to:

Syntax: ls /vol/<destination volume of the restored data>
e.g.: ls /vol/RKKNDMP

Following is the syntax used to create each of qtrees for an agentless backup job:
[JOBNAME]vCenter@VM

The JOBNAME is the saved job name for the original agentless backup job. The vCenter is the name of the vCenter server that contained the backed up VM. The VM is a HEX string representation of the VM’s bios.uuid.
Following is an example of the original saved job:

Following is an example of the original job definition for the agentless backup job:

Within each of these qtrees (VMs), a RAW image is created for each VMDK that was backed up. The number of RAW images can vary depending on how many VMDKs were on that VM at the time of backup. The uuid of the VMDK is used to create the RAW image name.

The following command is used to display the RAW image within each of the VMs:

Syntax: ls /vol/<destination volume of the restored data>/[JOBNAME]/vCenter@VM
e.g.: ls /vol/RKKNDMP/ [RKK_CPT5_AL1]syncvcenter2@D13DA539
e.g.: ls /vol/RKKNDMP/ [RKK_CPT5_AL1]syncvcenter2@D221A956

In cases where multiple VMDKs were backed up, the metadata file (shown in the illustration above) can be used to determine which RAW image pertains to which VMDK. Within the metadata file, entry tags (<entry> and </entry>) contain information about a specific VMDK. Inside each entry tag, an imageName tag (<imageName> and </imageName>) contains the RAW image name for a VMDK. The catalogID tag (<catalogID> and </catalogID>) is also located within the entry tag. The catalogID is used to find out the VMDK and hard disk name. Using the output of the ls command to get the RAW image name, it can be searched against contents of the metadata file to identify the correct VMDK to IA.

The metadata file can be opened through WordPad or using the command rdfile. The example below uses the output of ls for a specific qtree (VM) to get a listing of all the VMDKs. The RAW image name is then searched against the contents within the metadata file to determine the hard disk name.

Following is the output of ls displaying the RAW image names (VMDKs) for a VM (D13DA539):

Syntax: rdfile /vol/<destination volume of the restored data>/[JOBNAME]/vCenter@VM/metadata
e.g.: rdfile /vol/RKKNDMP/[RKK_CPT5_AL1]syncvcenter2@D13DA539/metadata
Raw Image name: 6000C29c-9fc0-432e-bb92-cd7688d783c7.RAW

Following is an example of an entry, imageName, and catalogID tag from a VM (D13DA539) metadata file:

<entry>
   <string>6000C29c-9fc0-432e-bb92-cd7688d783c7</string>
   <com.syncsort.bex.vilib.VMBackupDocument_-DiskData>
    <version>1.0</version>
    <path>[RKK_NFS] RKK_CPT_5_NFS/RKK_CPT_5_NFS-000003.vmdk</path>
    <jobid>1337399303</jobid>
    <diskID>6000C29c-9fc0-432e-bb92-cd7688d783c7</diskID>
    <catalogID>Hard disk 1 (RKK_CPT_5_NFS-000003.vmdk)</catalogID>
    <datastore>RKK_NFS</datastore>
    <index>0</index>
    <totalSize>26843545600</totalSize>
    <allocatedSize>-1</allocatedSize>
    <backupSize>7929856</backupSize>
    <backupDone>true</backupDone>
    <errorMessage/>
    <changeID>52 5f 25 80 01 c5 b7 8a-a9 b9 ea e2 44 ea d3 bf/10</changeID>
    <imageName>6000C29c-9fc0-432e-bb92-cd7688d783c7.RAW</imageName>
    <lunName>6000C29c-9fc0-432e-bb92-cd7688d783c7.LUN</lunName>
    <signature>-76612090</signature>
    <uuid>6000C29c-9fc0-432e-bb92-cd7688d783c7</uuid>
   </com.syncsort.bex.vilib.VMBackupDocument_-DiskData>
</entry>

Once the VMDK to IA is identified (using the catalogID), keep note of the imageName for that VMDK (it will be used later). Next, use a snapshot to backup the LUN to create. All the snapshots from the original volume were captured during the NDMP (SMTape) backup are present in the newly restored volume. The following command displays the available recovery points (snapshots) for a volume. In our example, there are two original recovery points from the agentless backup. When an agentless backup is complete, NSB invokes a snap create command on the destination volume. The naming convention used for these snapshots are vCenter_JOBNAME.snapshotid. Use the snap list output to determine the snapshot and date to IA from.
- Syntax: snap list <destination volume of the restored data>
- e.g.: snap list RKKNDMP
- Snapshot Syntax: vCenter_JOBNAME.snapshotid
- e.g.: syncvcenter2_RKK_CPT5_AL1.1337378803

To create a LUN that is backed by a snapshot, follow the commands below. Before running the lun create command, a snapmirror break must be issued on the destination volume of the restored data.
- Syntax: snapmirror break <destination volume of the restored data>
- e.g.: snapmirror break RKKNDMP

Syntax: lun create –b <snapshot_lun_path> -o noreserve <lun_path>
e.g.: lun create -b /vol/RKKNDMP/.snapshot/syncvcenter2_RKK_CPT5_AL1.1337378803/[RKK_CPT5_AL1]syncvcenter2@D13DA539/6000C29c-9fc0-432e-bb92-cd7688d783c7.RAW -o noreserve /vol/RKKNDMP/restore_lun

Syntax: snapshot_lun_path
1. /vol/volName/.snapshot/snapshotName/QTree/imageName
The snapshot_lun_path needs the following information:
1. volName – destination volume of restored data
  1. e.g.: RKKNDMP
2. snapshotName – point in time recovery
  1. e.g.: syncvcenter2_RKK_CPT5_AL1.1337378803
3. QTree – VM to IA from
  1. e.g.: syncvcenter2_RKK_CPT5_AL1.1337378803/[RKK_CPT5_AL1]syncvcenter2@D13DA539
4. imageName – VMDK to IA
  1. e.g.: 6000C29c-9fc0-432e-bb92-cd7688d783c7.RAW
Syntax: lun_path
1. /vol/volName/lunName
The lun_path needs the following information:
1. volName - destination volume of restored data

e.g.: RKKNDMP

lunName – unique name for the LUN

e.g.: restore_lun

Note: If the lun create command complains about the volume being in a read-only state, use the snapmirror break command on that volume.

The following command displays the LUNs on the NetApp storage system along with the newly created LUN for the IA mapping:

Syntax: lun show
e.g.: /vol/RKKNDMP/restore_lun 25g (26843545600) (r/w, online)

On the Windows server (iSCSI target machine) being IA mapped to, make a note of the Initiator Name, which can be found from the iSCSI Initiator Properties Window (started from Control Panel > iSCSI Initiator). The Initiator Name is used to create the iSCSI initiator group (iGroup) on the NetApp storage system.

After the LUN is created, the iSCSI target machine must be associated to an iGroup. To create the iGroup on the NetApp storage system, follow the commands below. A name must be given to the iGroup (IA_RESTORE and use the Initiator Name (iqn.1991-05.com.microsoft:axarkkmaster ) from the iSCSI target machine.
- Syntax: igroup create -i -t windows <initiator_group_name> <initiator_node_name>
- e.g.: igroup create -i -t windows IA_RESTORE iqn.1991-05.com.microsoft:axarkkmaster

The following command below displays the iGroups on the NetApp storage system along with the newly created iGroup:

Syntax: igroup show
e.g.: IA_RESTORE (iSCSI) (ostype: windows): iqn.1991-05.com.microsoft:axarkkmaster (not logged in)

Note: If an instant restore or Instant Virtualization was performed on the NetApp storage system before, an existing iGroup of type default may already exist. If this does exist, you MUST use the previously created iGroup by NSB or remove it first.

Map the LUN previously created to the newly created iGroup:
- Syntax: lun map <lun_path> <initiator_group_name>
- e.g.: lun map /vol/RKKNDMP/restore_lun IA_RESTORE

Note: You may need to specify a non-zero LUN ID to the target if there are multiple (active or dead) LUNs mapped from the NetApp to the ESX host when you map it with the lun map command. Use help lun map to see command usage on the NetApp.

Use the iSCSI Initiator on the Windows server to login to the iGroup on the NetApp storage system. The IP address of the NetApp storage system is used here.

Note: If iSCSI is installed and was used at some time, use the iSCSI initiator utility to log out of the NetApp storage system and log back in for the volumes to appear. Refer to the following:

In Disk Management, the iSCSI drives should appear. In some cases, a rescan and online of the disks may be necessary.

The data from the iSCSI drives can now be recovered. After they are recovered, disconnect from the NetApp storage system and destroy the created LUNs and volume.