Summary
This article explains how to protect data originally backed up to a SnapVault Secondary device on tertiary storage (in most cases tape) and recover from tertiary storage. This article assumes that the reader is familiar with the basic concepts of SnapVault, Open System SnapVault and NDMP.
Step By Step
Prerequisites
This article will explain how to protect data originally backed up to a SnapVault Secondary device on tertiary storage (in most cases tape). This article assumes that the reader is familiar with the basic concepts of SnapVault, Open System SnapVault and NDMP.
Archiving Secondary Data to Tertiary Media
Two methods exist for archiving the data that resides on the secondary device (filer or Nearstore device) to tertiary media. For the remainder of this document, we will assume that the tertiary media is tape, although one can also backup to tertiary disk if need be. Let’s discuss these two methods in more detail.
NDMP Backup
The easiest way to archive secondary data to tape would be through the NDMP backup functionality of Backup Express. Assume one has a tape library connected to the secondary filer (or connected to any host in the Backup Express enterprise for that matter). One would then define a NDMP backup by using the Backup Express GUI to backup the SnapVault data to tape. To do this, one would click on the Backup/NDMP option from the Backup Express Launch Panel and choose a snapshot on a volume to be backed up to tape. The recommendation is to periodically archive the latest snapshot on every volume used for SnapVault backups to tape. Remember that each volume on the secondary device has only one backup job that writes to that volume (see Article 39657). That implies that each volume will have snapshots created by a single Backup Express job. The naming convention of these snapshots are SSSV_<jobname>.n with <jobname> the name of the Backup Express job that writes to that volume, and n the number assigned to the snapshot. The latest snapshot is always denoted the number 0.
So on a typical volume (example /vol/HLPSVBU below) used as the destination for a Backup Express SnapVault job called OSSV_01 one may have the snapshots SSSV_OSSV_01.0, SSSV_WIN2K.1, and so on. A screenshot of the source panel in the Backup/NDMP window showing these snapshots is shown below. The red box shows an expanded view of the snapshots for this volume, while the green box shows the live file system housing all the QTrees.
In this example, the latest snapshot SSSV_OSSV_01.0 is selected for backup. This snapshot, which was created by the Backup Express SnapVault job, captures a point-in-time of all the QTrees on the volume. Typically one would schedule this job to run once a week as type Base to archive all the QTrees to tape (there is no concept of a Incremental or Differential backup of a snapshot since a snapshot is read-only by definition, and does therefore never change).
As the SnapVault data expires from the Backup Express catalog, the associated SnapShot is deleted by Backup Express. To recover the data from the archive on tape, one would have to restore the contents of the QTree to a filer first, and then iSCSI mount it to a Windows server in order to gain access to the files contained in the image file stored in the QTree. Note that the secondary filer needs to be licensed for iSCSI in order to do this, and that the iSCSI protocol needs to be enabled on the filer (options iscsi.enable on). This procedure is discussed in the next section. This does not apply to UNIX and ONTAP data which was SnapVaulted to the secondary since the data for that type of SnapVault job is stored at the file level (not the block level) and can therefore be recovered at the file level.
NDMP Restore, LUN Creation and Sharing
In order to recover the contents of logical drive (E: drive for instance) that was archived to tertiary media by using the Backup Express NDMP functionality, one needs to first identify the QTree that contains the appropriate .RAW file that corresponds to the logical drive on the server to be recovered. As mentioned above, imbedded in the QTree name is the name of the server which data it contains (DEMO001 and WIN2KHLP01 in the example above). To restore say the E: drive on the server WIN2KHLP01, one will first need to identify which of the two QTrees contains the .RAW file that corresponds to the drive that needs to be recovered. If this server is still part of the Backup Express Enterprise, this can be done by opening the Backup|Raw window from the Launch Panel, and then browse the server which will display the logical drive id’s for each drive. By comparing those to the ones listed in the QTree name, one can identify the correct QTree. In the event that the server is no longer part of the Backup Express Enterprise, one can either issue the mountvol command from a DOS window on the server to get a list of drive\disk id pairs, or restore the volmap.txt file from the APPS: QTree which contains this information. The following screenshot shows the Restore|NDMP window for defining this restore job
Restore this file to a new location on any filer and make sure to select the NDMP Recover Mode of Direct under the Restore Destination Options Window which will enable the Direct Access Restore (DAR) capability of DPX (this will greatly reduce the overall restore time). This file contains the drive-id-to-drive-letter mapping which will allow one to identify the QTree that contains the files needed to be restored. An example of the contents of this file is shown below:
E:|45CA01E3194A11D993FF000C291EBF59
C:|D1CC52C1072311D984DD806D6172696F
This shows that .RAW file corresponding to the E: drive we want to recover is contained in the QTree named
[OSSV_01]WIN2KHLP01@45CA01E3194A11D993FF000C291EBF59
This QTree contains two files: BEXIMAGE.TOC and BEXIMAGE.RAW (as shown below). Select the BEXIMAGE.RAW file to be restored to a new location on any filer, making sure that the destination volume has enough available space to house this potentially large file. In the example shown below, DPX will create a new directory (called RESTORE) to house the file. This menu is displayed when one right-clicks on the volume or folder which should house the new directory. As earlier make sure to enable the DAR capability when running this recovery.
After the restore, the file will be located in a subdirectory of the RESTORE folder, as shown below as viewed from Microsoft Explorer from a Windows server
To make the next few steps easier, move the BEXIMAGE.RAW file from the RESTORE\[OSSV_01]WIN2KHLP01@... folder to the RESTORE folder. This step is not necessary, but simplifies the path to the file which is needed in the next steps.
Before the file can be shared to a Windows host via the iSCSI protocol, a LUN backed by a snapshot that contains the file needs to be created first. So as a first step, create a snapshot on the volume that contains the restore .RAW file. To do this, issue the following command on the filer (from a telnet session or rsh):
snap create <volume_name> <snapshot_name>
with <volume_name> the name of the volume containing the restored .RAW file, and <snapshot_name> the name given to the snapshot. An example session shown below:
In this example, the snapshot SSRESTORE is created on the volume HLPSVBU, and the snap list command on the filer shows the newly created snapshot. To create a LUN that is now backed by this snapshot, one would use the lun create command so
lun create –b <snapshot_lun_path> -o noreserve <lun_path>
This command will create a lun with name <lun_path> backed by the file <snapshot_lun_path> that is contained in a snapshot. In our example this command will look so
A lun show command shows the existence of this newly created lun. Note that since file reservation is disabled for the .RAW file (this is because the backup volumes have volume reservation disabled – the size of the file as displayed here is not guaranteed, which means that although the LUN shows up to have a size of 4.0 GB (in this example), this data volume is not reserved on the volume.
In order to share this LUN to a Windows server, the Microsoft iSCSI Initiator needs to be installed on the Windows server. This software can be downloaded from www.microsoft.com/downloads. At time of writing version 2.0 was available for download, and will be used in the examples shown below.
After installing the iSCSI initiator on the Windows server, make a note of the initiator node name (shown in yellow), which can be found from the iSCSI Initiator Properties Window (started from Control Panel|iSCSI Initiator). This initiator node name is used to create the iSCSI initiator group on the filer.
To create the initiator group on the filer, issue the command:
igroup create –i –t windows <initiator_group_name> <initiator_node_name>
with <initiator_group_name> the name of the iSCSI (-i option) initiator group created on the filer, and <initiator_node_name> the node to be added to this group.
In our example this command will look so:
The igroup show command shows the existence of the group RESTORE_GROUP containing our node after successfully completing the igroup create command. The next step would now be to add the LUN created earlier to this newly created initiator group. This is done by issuing the lun map command from the filer:
lun map <lun_path> <initiator_group_name>
with <lun_path> and <initiator_group_name> as defined above. In the example below, the lun show command issued prior to and after issuing the lun map command shows that the lun is successfully mapped:
At this point the one can use the iSCSI Initiator on the Windows server to log into the initiator group on the filer. This is done using the iSCSI Initiator tool from Control Panel|iSCSI Initiator. As a first step, the target portal (filer that houses the LUN) should be added to the list of available portals on the Windows server. To do this (using version 2.0 of the Microsoft iSCSI Initiator) click on Discovery, and Add under the Target Portals panel. Then enter the hostname or IP Address of the filer that houses the LUN and click on OK. This target portal will now show up as an available portal.
If the LUN will be mapped to a WIN2003 server then issue the command mountvol /E from a DOS prompt before continuing. This command allows for automatic mounting of new volumes, which may be disabled. The final step would now be to log in to this target. To do this, select the Targets Tab, then the target to which one wants to connect and click on Log On. The status of the Target should now change to Connected, as shown below.
A new block-level logical disk will now be visible through Windows Explorer on the Windows server. One can simply use Explorer to copy the data from this disk to a local disk. And since this is a block-level device, it can be used as the data disk for a database (Exchange or SQL for instance). Just keep in mind that all the changes made to this disk will be on the filer, and will be lost of the LUN is destroyed. After the files are recovered, make sure to log off the map (click on Details from the window above, select the appropriate session, and click Log Off). Then on the filer, issue the commands
lun offline <lun_path>
lun destroy <lun_path>
An example is shown below:
These two commands will delete the LUN on the filer. After the LUN is deleted, also delete the snapshot created used to create the LUN, by issuing the following command on the filer:
snap delete <volume_name> <snapshot_name>
As a final step, delete the BEXIMAGE.RAW file, and the temporary folder from the filer that were used to house this file.
File Backup through Windows Host
An alternative way of archiving SnapVaulted data to tape would be to back it up through a Windows host as a file level backup (Backup/File from the Backup Express GUI). This would then allow for the data to be restored at the file level directly from tape to server without restoring to a filer first. In order to do this, one would have to iSCSI map the contents of the QTrees (using the Instant Availability function in Backup Express) to a host server running Windows before running the archive backup job to tape. The iSCSI drive on this Windows host will be the source of the archive backup job. This job will preserve the file history information and will allow for the data to be restored without the need to recover the image file to the filer as an intermediate step.
The problem however in archiving the data this way is that the data will be cataloged not as part of the original server from where is was (OSSV) backed up from, but from the server and drive where the volume was iSCSI mapped to. As an example, let us assume the D: drive on Server A is OSSV backed up to the filer, and then iSCSI mapped to the F: drive on Server B. It is this F: drive that will then be backed up to tape, and will hence be cataloged so. In the event that the user wants to recover the data from tape at a later stage, he/she needs to remember that the F: drive on Server B on a particular date corresponded to the data from the D: drive on Server A backed up on yet an earlier date. And since one only has a maximum of 26 maps to work with on a particular server, there will definitely be drive overlaps (F: drive on server B can correspond to the D: drive on Server A today, but a whole other server tomorrow), especially in a mid- to large size environment. One way to keep track of this drive letter swapping issue is to create a file on each drive that is OSSV backed up that corresponds to the server and drive letter, i.e. in our example above, create a file SERVER_A_DRIVE_D in the root of the D: drive on Server A. At time of restore from tape, one can then search the catalog for this file pertaining to the server and drive on which the file reside that needs to be restored.
In Closing
Each of the archiving methods described above requires the definition of a second backup job with a schedule and retention period independent of the SnapVault job that is written to that volume. One can therefore have the SnapVault jobs scheduled to run daily and have the archival job(s) scheduled to run (say) the first Saturday of every month, backing up the latest data set from the SnapVault job. At present there is no interaction between these two jobs.