*An update to this post
here
Previously I had listed
3 options for restoring from the SV-SMVI SnapVaulted VM backups. An additional
optional is to use CIFS.
There are 4
options to restore data from the SnapVault secondary:
Option 1: CIFS
Option 2: SnapVault
Option 3: NFS
Option 4: FlexClone
Option 1:
Configure the SnapVault secondary volumes as a CIFS share
The share can be enabled prior to any restore being
required. It is recommended to suspend the backup schedule prior to restoring
from the CIFS share.
Data ONTAP CLI commands to create and enable a share:
FAS-SEC> cifs
shares -add SV_SEC_VOL /vol/SV_SEC_VOL
FAS-SEC> cifs
access SV_SEC_VOL root “Full Control”
Additionally, since the primary volume has a UNIX
security style and VMware gives some read permissions only to root, the Windows
user will need to be mapped to root by editing the /etc/usermap.cfg file:
FAS-SEC> wrfile
-a /etc/usermap.cfg DOMAIN\USER1 => root
Note: To map all users to root, you can run options wafl.default_unix_user root (not recommended though for security reasons!)
Note: If CIFS is
not already enabled, license CIFS first, and the run CIFS setup with
FAS-SEC> license add CIFSCODEHERE
FAS-SEC> cifs setup
Option 2:
Perform a SnapVault Restore from SnapVault secondary to a Qtree on the primary
Suspend the SV-SMVI VSC backup job schedule.
On the secondary, obtain Qtree name, and list of
SnapVault secondary snapshots:
FAS-SEC> qtree
status SV_SEC_VOL
FAS-SEC> snap
list SV_SEC_VOL
On the primary, run snapvault restore and snapvault
status to check on progress:
FAS-PRI> snapvault
restore -s sv_pri_vol_backupname.X -S FAS-SEC:/vol/SV_SEC_VOL/QTREE_NFS
/vol/SV_PRI_VOL/RESTORE_QTREE
FAS-PRI> snapvault
status
Note: When the
SnapVault restore from the secondary to the primary is complete, state will be
Broken-off.
We can then add the VM to be restored to the vCenter
inventory and/or attach a VMDK to a live server.
To remove the reverse relationship created by the
restore, on the secondary run:
FAS-SEC> snapvault
destinations
FAS-SEC> snapvault
release /vol/SV_SEC_VOL/QTREE_NFS
FAS-PRI:/vol/SV_PRI_VOL/RESTORE_QTREE
On the primary, remove the snapshot that was created for
the Qtree SnapMirror (for the SnapVault restore):
FAS-PRI> snap
list SV_PRI_VOL
FAS-PRI> snap
delete -V SV_PRI_VOL FAS-PRI(XXX)_SV_PRI_VOL_RESTORE_QTREE-dst.X
FAS-PRI> snapvault
status
Option 3: Mount
the SnapVault secondary volume as a read-only NFS datastore
Note: This requires
an NFS license on the SnapVault secondary.
First of all, suspend the VSC backup job schedule.
Configure the exports on the SnapVault Secondary as in
the example below:
FAS-SEC> exportfs
-p rw=10.0.0.0/24,root=10.0.0.0/24
/vol/SV_SEC_VOL
In the vSphere Client, mount the volume as a read only
NFS datastore.
We can then browse the datastore and .snapshot folder for
backups, and copy the data (VMDKs etcetera) as required.
Option 4:
FlexClone a SnapVault secondary volume/snapshot and mount as writeable
Note: This requires
a FlexClone license on the SnapVault secondary.
Create a Flex Clone volume from the SnapVault secondary
volume choosing snapshot required:
FAS-SEC> snap
list SV_SEC_VOL
FAS-SEC> vol
clone create SV_SEC_VOL_FLEXCLONE -s none -b SV_SEC_VOL
sv_pri_vol_backupname.X
In the vSphere Client, mount the volume as an NFS
datastore (this time not read only).
We can then add the VM to be restored to the vCenter
inventory and/or attach a VMDK to a live server.
When finished - via the vSphere Client -
unmount/unregister any VMs/disks and unmount the datastore.
Finally, from the Data ONTAP CLI on the SnapVault
Secondary, offline the FlexClone volume and destroy it
FAS-SEC> vol
offline SV_SEC_VOL_FLEXCLONE
FAS-SEC> vol
destroy SV_SEC_VOL_FLEXCLONE
Comments
Post a Comment