2011-11-14 07:38 PM
Current setup: FAS3240 cluster running DOT 8.0.1P4 and VSC 2.1 installed on vCenter server.
VSC is configured to take snapshots backup's on the primary and retain it for 3 days and then it is snapvaulted back to the other SATA cluster head using sv-smvi script in the VSC and backup's are retained for 30 days.
Currently we have one nightly backup everyday consisting of three datastores happening @2:30 am.
Assumptions: Assuming that we cannot do a snapvault restore at a file level as we do using snap restore command ( Please Correct me if I am wrong)
Requirement: If an administrator request us to restore a VM which is more than three days, the only way of restoring will be from the snapvault destination. I can think of only one option, if anyone out there has a better option please let me know.
Snapvault restore to another volume on the primary using the specified snapshot and then export that volume to the ESX host, once exported mount that volume as datastore and browse that datastore go to that particular VM folder copy the folder across to the original datastore. Rename and add it to inventory and power it on. When I think of snapvault restore to another volume my concern would be how long it is going to take to do a restore is this going to be new baseline transfer as this another volume.
Can someone please shed some light!!!!!!!!!!!!!!!!!!!!!!!! I am looking for any other option without copying the VM folder.
2011-11-15 06:29 AM
Until SMVI has integration with Protection Manager for archived backups, manually copying the files is your only option. You can use Protection Manager to do this - it issues an ndmpcopy from the snapvault secondary back to the primary.
2011-12-01 02:24 PM
Are you using NFS or VMFS to store your guest OS files? If you are using NFS, you may have a few more options since the NetApp will be able to handle the data is files instead of as SCSI blocks. According to my training on Data OnTap 7.3, single-file restore cannot be performed with SnapVault restore commands. However, there are other options.
If the SnapVault Secondary controller has a FlexClone license, restoring a singe VM can be accomplished as follows.
1. Clone the volume which contains the SnapVault destination qtree. Base the clone on the snapshot which contains the appropriate data set.
2. Connect the cloned volume to the ESX environment
2a. If the SnapVault Primary controller uses iSCSI/FC/FCoE, the SnapVault Secondary controller can use iSCSI (if connecting the SnapVault Secondary to the FC/FCoE fabric is expensive/difficult/infeasible) or FC or FCoE.
2b. If the SnapVault Primary controller uses NFS, the SnapVault Secondary controller should also use NFS.
3. Use Storage vMotion to move the guest OS from the Secondary storage to the Primary storage.
4. Disconnect the cloned Volume from the ESX environment.
5. Destroy the volume clone.
If the storage is presented to ESX as an NFS export (which seems likely given your description), if FlexClone is not available, restoring a single VM will require the following:
1. Knowledge of the required file names and their paths
2. Copying the files from the read-only SnapVault Secondary qtree to writable storage
2a. As mentioned above, this can be done with Protection Manager or ndmpcopy
2b. It can also be done by exporting the appropriate path on the SnapVault Secondary controller and copying the files with the cp (or similar) command.
If the storage is presented to ESX as a LUN, then the entire LUN must be restored or cloned to access the files for the guest OS. Since SnapVault uses qtrees, you may be able to perform LUN cloning within the SnapVault Secondary volume. LUN clones do not require a FlexClone license. LUN clones must reside in the same volume as their parent LUN. I cannot readily identify whether LUN clones need to remain in the same qtree as the parent LUN. If LUN clones can be in a different qtree than the parent LUN, then a LUN clone can be created. (The SnapVault secondary qtree will be read-only, but the LUN clone will need to be writable to use Storave vMotion). In this scenario, the high level view of the DRP for restoring a single VM from the SnapVault Secondary Server would look something like this.
1. Create LUN clone based on the required snapshot
2. Export the LUN clone using iSCSI (or FC/FCoE, if available)
3. Mount the LUN clone within VMware ESX.
4. Use Storage vMotion to move the restored guest OS from the SnapVault Secondary storage to primary storage
5. Unmount the LUN clone
6. Unexport the LUN clone
7. Destroy the LUN clone
Please let me know if you need any assistance adding greater detail to any of these steps.