Recovery options
You need to plan the backup and recovery of your VMware environment carefully, depending on your requirements. The reason for recovery might require one of the following main strategies:
•Recovery from a failed or corrupted LUN or volume
•Recovery from a failed server (guest)
•Recovery from accidental deletion of user files
For information about recovery from a failed storage system, ESX server, or whole server environment, see Chapter 12, “High availability and disaster recovery” on page 215.
Recovery of a snapshot can be done at the volume or LUN level directly from the N series system. Files or guests can be recovered only by using a clone of a LUN that is mounted and that restores the required data.
This chapter includes the following topics:
10.1 Restoring a volume
Restoring volumes requires retrieving data from a snapshot, so you must have at least one in order to restore a volume. Snapshot creation and scheduling are covered in Chapter 9, “Configuring snapshots” on page 169.
Restoring a volume from a snapshot overwrites the existing volume with the backup version. You might want to perform this task where a volume was unintentionally deleted or corrupted.
To restore a volume, use the Data ONTAP FilerView tool as follows:
Figure 10-1 Volume restore
2. In the Welcome pane of the Volume Restore Wizard, which guides you through the restoration process as in Figure 10-2, click Next.
Figure 10-2 Volume Restore Wizard
Figure 10-3 Selecting the volume to restore
4. In the Snapshots pane (Figure 10-4), select the snapshot that you want to restore. If you choose an old snapshot, all newer snapshots become unavailable for future restores. Click Next.
Figure 10-4 Selecting the volume snapshot
5. In the Commit pane (Figure 10-5), check the details of the restore that you requested, and click Commit if you want to do the restore.
Figure 10-5 Committing the volume restore
6. In the Success pane (Figure 10-6), verify that the volume restore process completed successfully, and click Close.
Figure 10-6 Completing the volume restore
10.2 Restoring data from a cloned volume, as with FlexClone
To restore a volume while keeping the existing volume intact, a clone of a snapshot backup is required. You do this process when only some of the data from a volume was lost or needs to be recovered.
|
Preferred practice: Use the clone for a short time while data recovery is occurring, and then destroy it. Do not take snapshots while the clone exists, which can lead to contention.
|
10.2.1 Creating a clone
To create a clone, using FilerView, complete these steps:
1. In the left navigation pane of the FilerView window (Figure 10-7), select Volumes → FlexClone → Create.
Figure 10-7 Creating a FlexClone
2. In the Welcome pane (Figure 10-8) of the FlexClone Wizard, which steps you through the cloning process, click Next.
Figure 10-8 FlexClone Wizard
3. In the Clone a Flexible Volume pane (Figure 10-9), enter the name of the new clone. Select the volume to be cloned and the Space Guarantee option that you require.
Click Next.
Click Next.
Figure 10-9 FlexClone settings
4. In the Parent Snapshot pane (Figure 10-10), select the snapshot of the volume that you want to clone. This step is not a destructive action like the volume restore. More recent snapshots are still available after the clone is complete. Click Next.
Figure 10-10 Selecting the snapshot for FlexClone
5. In the Commit pane (Figure 10-11), check the details of the FlexClone that you requested. Click Commit if you want to create the clone.
Figure 10-11 Committing the FlexClone creation
6. In the Success pane (Figure 10-12), verify that the FlexClone creation process completed successfully, and click Close.
Figure 10-12 FlexClone creation complete
Now the clone is created, and all data (including LUNs) that was in the original volume, when the Snapshot was taken, is also there. Any LUNs, however, are not mapped, and therefore, cannot be mounted.
|
Alternative process: This process uses the FlexClone feature in FilerView. Alternatively, you can use the following command on the N series command line:
lun clone create <clone_lunpath> [-o noreserve] -b <parent_lunpath> <parent_snap>
|
10.2.2 Configuring the cloned LUN to be accessed
After the clone is created, you must bring online the LUNs (if any) that you want to access. Map the LUN to a host or hosts, then create a datastore over it.
Mapping a LUN to hosts
1. In the FilerView window, in the left navigation pane, select LUNs → Manage, and you see the cloned LUN, as in Figure 10-13. It is offline and not mapped to any host, so we want to configure it.
Figure 10-13 The cloned LUN
Figure 10-14 Making the LUN Online
3. Then click LUNs → Manage again and click No Maps on the cloned LUN. It opens a panel to select the Initiator Group, as in Figure 10-15. Click Add Groups to Map.
Figure 10-15 Add Groups to Map
Figure 10-16 Selecting Initiator Group
Figure 10-17 LUN ID for the cloned LUN
6. A Success message displays, as in Figure 10-18.
Figure 10-18 Cloned LUN configuration completed on N series
Creating a datastore with the cloned LUN on VMware
Follow these steps:
1. On VMware side, select a host present on the initiator group and click Rescan All. Go to the Storage Adapters menu and select the iSCSI connection. You see the new LUN 11 available on the host, as shown in Figure 10-19.
Figure 10-19 The cloned volume shown with the LUN number defined on N series
2. Click Storage, then click Add Storage...
3. On the Add Storage menu, select Disk/LUN and click Next.
4. The cloned LUN is available with the VMFS label as the name of the datastore from which the LUN was cloned. Select the cloned LUN and click Next.
5. In the Mount Options panel, change the radio button to Assign a new signature, as shown in Figure 10-20. That option enables the copy from the cloned datastore into the existing one.
Figure 10-20 Changing to Assign a new signature
6. Review the information shown on the Current Disk Partition and click Next.
7. In the Ready to Complete panel, observe that a new signature is going to be applied to the LUN, as in Figure 10-21. Click Finish.
Figure 10-21 A new signature is applied to the LUN
8. After adding the datastore, it will have a name referencing the cloned LUN/datastore, as shown in Figure 10-22.
Figure 10-22 The cloned LUN creates a datastore referring the original one
10.3 Recovering an entire virtual machine
To recover a guest because of data corruption, the original guest files are replaced with the files of the cloned guest created in the previous sections.
10.3.1 Copying data into the original guest datastore
If you are restoring all of the virtual machines, then they probably have a problem and are down. If they are still running, make sure to turn them off before copying data over them.
To recover an entire virtual machine, follow these steps:
1. Browse the guest datastore, as in Figure 10-23.
Figure 10-23 Browsing the datastore from where data is to be copied
2. Browse to the folder of the virtual machine to be recovered. Select all the files, right-click them, and click Copy, as in Figure 10-24.
Figure 10-24 Copying the files from the cloned datastore
3. Browse to the original datastore, go to the virtual machine to be restored, right-click a blank area, and select Paste, as in Figure 10-25.
Figure 10-25 Pasting the VM files over the original datastore / VM folder
4. Click all Yes boxes to confirm the overwriting of its data.
5. Observe the progress of the copies on the Recent Tasks tab, as in Figure 10-26.
Figure 10-26 The copy data completion status on Recent Tasks tab
6. At the end of the data moving, start the virtual machine if you want.
7. If the cloned LUN/datastore contains a snapshot, use Snapshot Manager to delete it, which commits the data from the delta disks into the original virtual disk.
10.3.2 Recovering the RDM from Snapshot copy
Recovering the Raw Device Mapping (RDM) from a Snapshot is quick and easy. You shut down the VM, replace the LUN, and start the VM again, as explained in the following steps:
1. Open vCenter.
2. Select the guest you want and power it off.
3. Connect to the N series system console through SSH, telnet, or a console connection.
4. Clone the original LUN from a recent Snapshot copy:
lun clone create <clone LUN path> –b <original LUN path> <Snapshot name>
5. Take the current version of the LUN in use offline:
lun offline <LUN path>
6. Bring the cloned LUN online:
lun online <LUN path>
7. Map the cloned LUN:
lun map <LUN path> <igroup> <ID>
8. Back on vCenter, select the virtual machine you changed and power it on.
9. Validate that the restore is to the correct version. Log in to the virtual machine, and verify that the system was restored to the proper point in time.
10. Connect to the N series system console through SSH, telnet, or a console connection.
11. Delete the original LUN:
lun destroy –f <original LUN path>
12. Split the clone into a whole LUN:
lun clone split start <cloned LUN path>
13. Optional: Rename the cloned LUN to the name of the original LUN:
lun mv <cloned LUN path> <original LUN path>
10.3.3 Recovering virtual machines from an NFS Snapshot copy
NFS provides a quick method to recover a guest from a Snapshot copy.
In summary, the process described next powers off the guest, restores the virtual disk (.vmdk), and powers on the guest. To complete this process, follow these steps:
1. Open vCenter.
2. Select the d virtual machine you want and power it off.
3. Browse the datastore where the .vmdk are located and go to the folder containing those files.
4. Rename the .vmdk, so a new file can be created when recovered from N series Snapshot.
5. Connect to the N series system console through SSH, telnet, or a console connection.
6. Restore the VMDK file from a recent Snapshot copy:
snap restore –t file -s <snapshot-name> <original VMDK path> <original VMDK path>
7. Return to vCenter, select the virtual machine, and start it.
8. Validate that the restore is to the correct version. Log in to the guest, and verify that the system was restored to the proper point in time.
9. Delete the renamed .vmdk files from the datastore, browsing it.
10.4 Recovering files within a guest
Rather than recovering a whole guest from backup, sometimes only a few files need to be recovered within the guest. You can recover those files directly if the guest has backup client software installed and is sending backups to a central backup server. But if the only backup available is the entire LUN, an alternative method must be used.
If snapshots are implemented, files can be recovered from a cloned snapshot with no additional backup infrastructure required. Because the files are encapsulated within the guest .vmdk file, the file must be mounted by a virtual machine on the target server or another virtual machine.
|
Tip: Using the target guest to mount the cloned .vmdk file is the most straightforward method. However, unmounting the file requires an outage on the guest. Therefore, plan for its use on a production guest. This example uses a temporary VM created for this task that can be removed after the recovery is complete, or kept for future file recoveries.
|
10.4.1 Creating a temporary recovery guest
You can create a temporary guest from a template or installing the operating system (OS) from a media. The temporary virtual machine must be compatible with the original OS.
10.4.2 Connecting the cloned virtual disk to the temporary guest
After the guest is created (our VM is named Temp-VM), connect it to the cloned guest disk:
1. Right-click the temporary guest and select Edit Settings
Figure 10-27 Adding disk to the temporary VM
3. Select Hard Disk and click Next.
Figure 10-28 Adding an existing disk
5. On Select Existing Disk, browse to the datastore mounted over the recovered LUN. Find the disk from where the data is to be copied, as shown in Figure 10-29, then click Next.
Figure 10-29 Browse recovery datastore until finding the .vmdk containing the data wanted
6. On the next panel, Advanced Options, accept the default SCSI controller being assigned to the disk and click Next.
7. On the Ready to Complete panel, review the entered information and click Finish.
8. Check the Recent Tasks list for successful reconfiguration of the guest (Figure 10-30).
Figure 10-30 Completion of the adding disk task
10.4.3 Copying the files to the target guest
The temporary guest is now ready to be started in order to provide the data back to the original virtual machine. We now actually copy the data from one to another, as shown in the following steps:
1. Right-click the temporary guest, select Power and then Power On.
2. To access the guest, log on to the console. Right-click it and select Open Console.
3. After the OS comes up, log to it and set an IP, so it can share data with the original virtual machine. You might get a warning saying that the OS completed the installation of a new device (the added disk), requesting a restart. As a restart is not necessary, click No.
4. Notice how the guest has a second local disk, which is E: in this case. This disk is the cloned disk from where the data is to be recovered (Figure 10-31).
Figure 10-31 The disk from which the data is to be recovered
5. Map a network drive pointing to the original virtual machine (in this case, Prod-VM) and the disk to receive the restored data (Figure 10-32).
Figure 10-32 Mapping the destination drive on the original virtual machine
6. Copy the data from your restored VM into the mapped drive.
10.4.4 Disconnecting the cloned disk from the temporary guest
After file recovery is completed, shut down the temporary guest, so that the cloned disk can be disconnected:
1. Shut down the OS to avoid corruption. This process shuts down the VM as well.
2. After the guest is down, right-click the temporary VM and click Edit Settings...
3. Select the cloned disk, and click Remove
4. The Virtual Machine Properties window gives you two options. As the LUN is intended to be removed later, there is no need to destroy the data. So we select Remove from virtual machine as in Figure 10-33, then click OK.
Figure 10-33 Removing the disk from the VM
5. Verify that the Recent Tasks list to confirm that the disk was removed, as in Figure 10-34.
Figure 10-34 Completion of disk removal
10.4.5 Removing the cloned LUN
After the recovery of the VMware guest or data from the cloned LUN, you must delete the cloned LUN so that N series Snapshot backups can be started again.
|
Preparation: Ensure that any VMware guests that were connected to the cloned LUNs are disconnected before deleting the clone.
|
To remove the clone, follow these steps:
1. In FilerView, from the left navigation pane (Figure 10-35), select Volumes → Manage. Select the cloned volume and click Offline, as shown in Figure 10-35.
Figure 10-35 Selecting the volume and taking it offline
2. Click OK to confirm taking the volume offline and then check the success message on Manage Volumes, as in Figure 10-36.
Figure 10-36 Take volume offline
3. Select the volume again, but this time, click the Destroy button.
4. Click OK to confirm that you want to destroy the volume that is shown.
5. Now the Manage Volumes pane (Figure 10-37) indicates that Destroy function was successful, and the volume is not present on the list anymore.
Figure 10-37 The success message after destroying the volume
6. You will see the datastore related to that LUN grayed, as it is unavailable (Figure 10-38).
Figure 10-38 Datastore grayed due to LUN unavailability
Figure 10-39 Grayed datastore not on the list anymore after a rescan
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.