rfenton

Easy Single File Restore from a VM

Blog Post created by rfenton Employee on Nov 12, 2013

Pssssst,  do you want a know a secret ?  It's a ridiculously simple way to do perform a single file restore from an active virtual machine.  It uses no tapes, hardly any storage space and most importantly it will take literally all of 5 minutes ??  Interested ? Well read on....

 

Before I get to the 'secret sauce'  I have to say 'I love snapshots'. They are a paradigm shift and game changer when it comes to backup and more importantly restore.  They also form a cornerstone of this pretty cool technique (my opinion) that I will show you.  Of course not all snapshots are born equally. Pretty much every array and many software platforms offer some form of snapshot implementation but how we vendors implement and to what effectiveness differs wildly.  I'm not going to dive into the Nimble's snapshot implementation details in this blog, if you want to understand whats happening underneath the covers in more detail then I would heartily recommend a quick read of the following blog - O'Snapshot What Art Thou ? Needless to say, Nimble snapshots are a great example of the most effective type of snapshots: Redirect-On-Write Snapshots and provide our customers with some compelling benefits:

 

  • No performance degradation (whether you have 1 snapshot of a volume or 1,000 snapshots of that same volume).
  • You can take them a frequently as you like (within reason);  Why backup once a day when I can backup multiple times per hour ?
  • They take up very little space (Compressed Incremental Block Changes is the only data that is stored).
  • They are always online and full backups.
  • They can readily cloned for a variety of purposes (Restores, QA, Development/Testing, Post-Mortem/Root cause analysis).
  • Restores are simple and super fast - allowing for decreased recovery times and increased application availability.
  • Thanks to CASL, they are stored inherently on the most cost-effective on-line medium (High capacity, Low RPM disk drives) and not associated to costly high performance storage.

 

The most important point of all the above is Restores;  I used to work with a colleague who's mantra was 'Backup flatters, Restore matters'.  As the Nimble removes the often found limitations of many snapshot implementations (namely, performance degradation, space utilisation, fragmented filesystem), it allows our customers to backup more frequently and therefore hold the point in time backups online for longer, allowing for much more effective restores.  Compare the following application with a traditional backup architecture and effective snapshot and the restore options available at the point of time of a disaster:

Restore1.png

A database fails mid afternoon, I go back to my previous nights backup/dump, copy the data back and then replay forward to the point of corruption.  A huge amount of effort and time to get application back in service.  Alternatively if I am backing up using snapshots then I have a much closer restore to choose from:

Restore2.png

It takes no time to restore the data (as there is no data movement, just a manipulation of metadata) and I am much closer to point of disaster.   It's a very different way to look at at conventional backup and restore.

 

 

Enough of this...Let's cut to chase...The Secret Sauce... the following is a demo I created that utilises snapshots to do a single file restore from a virtual machine.  It has three integral components:   Nimble Snapshots, Nimble Cloning and a piece of third party software called UFS Explorer.  Both Snapshot and Cloning are features ship with every Nimble array so no license is required to use this functionality.

 

Firstly I have a VMFS datastore hosted on a Nimble Storage array which is supporting a number of Guests... The datastore is esx-ds1

Restore4.png

 

and that is hosted on my Nimble volume (esx-ds1):

Restore5.png

 

The screenshot above shows the primary volume, it's size, it's I/O and note on the left handside this volume currently has 46 snapshots;

 

In order for this demonstration I am going to delete a file from my vCenter server and then individually restore that file using a snapshot backup and clone.

Note: There is no prerequisite to use vCenter it just happens to be the host that I am deleting the file and where I have installed the UFS Explorer application.

 

So now I am going to delete a file (SDelete.zip) to give us something to selectively restore...

 

Restore3.png

 

If we now navigate to Snapshots tab of the esx-ds1 volume, we see a list of all the snapshots, including the time they were taken and the amount of space they currently consume.  This particular volume is being backed up once every 2 hours and once a day with the daily snapshots being held for 30 days.   I select the snapshot I wish to restore from (in this case a snapshot for a couple of days ago).  At this point I could choose to unmount the datastore and restore the entire volume (which would restore, almost instantaneously, the volume to the point of time of the backup), however that doesn't make sense as all the VM's and Filesystems located on that datastore would be restored to that point of time and I only wish to restore the single file I deleted earlier. Instead I am going to create a Nimble clone from that snapshot.  Again this is an instantaneous option as it's just a copy of metadata and will consume zero space.  As a user the only thing I have to do if give the volume a unique name (RF-SingleFileRestore in this case) and click OK.

Restore6.png

 

Once completed I have a new cloned volume that consumes no space, that s based on my chosen backup that I selected from the snapshot list...

 

Restore7.png

Note the space consumption and the parent/snapshot volume in the top right hand corner.  As this clone is based of esx-ds1 the Nimble GUI has automatically given it access to my esx cluster (as that is where the parent was mounted to);  So I am going to remap this clone to the host where I am going to run the restore from (my vCenter server for this demonstration).  In order to do this I edit the volume and change the access control list to remove the ESX cluster and add my vCenter host.

 

Restore8.png

 

Now if I check the vCenter host software iSCSI initiator, I should be able to connect to the clone and see it from the Operating System....

 

Recover10.png

 

and then see the volume is Disk Manager (Disk 1).  Note: I don't want to format this volume and put NTFS on there as it's a VMFS volume and my backup data is already there.  Just leave it as a Physical device.

Restore9.png

 

So the above there has been a few steps to get us to this point, but I wanted the reader to be aware of the steps and what is going on with the snapshots and clones.  The beauty is all the steps up to this point can be completely automated with a simple script to select a volume, snapshot, clone and mount.

 

 

So final step is to utilise UFS Explorer to pull back the file... On starting UFS Explorer Professional Recovery, you will see all the drives that the host can see - it's C-Drive, VMDK and most importantly the clone that I mapped to my guest in the previous step....

 

Restore11.png

 

Selecting the clone and right clicking it will allow you to open and browse the VMFS filesystem....

 

Restore12.png

 

In the right hand pane, I will now see all my guests hosted on the datastore and I can drill into each one.  Now I select the guest that I want to do my individual file restore from (my vCenter server in this example), clicking on vcenter will show me the guests VMWare files (vmdk's vmx files that are associated to the guest).  Next I navigate to the guests vmdk and again right click the file and select Open file as a disk image.  This will now open a new drive in my left hand pane which is that VMDK (vcenter-flat.vmdk):

 

Restore13.png

 

Now I can select that drive (Open the file system)

 

Restore14.png

 

and navigate it finding the file I wish to restore (remember this is the guest's filesystem when the snapshot was taken).  Apparently there is a function in UFS Explorer to scan and index the contents of the volume but I will save that for a future blog.

 

Restore15.png

 

Once the file I wish to restore is located, you can right click it and 'Save this Object' back to the guest local filesystem...

 

Restore16.png

 

Choosing the location where the object needs to be restored too...

 

Restore17.png

 

and that's it - the file is back....

 

Restore18.png

 

 

In order to clean up;  Close the UFS Explorer application and Offline and delete the Clone Volume from the Nimble GUI.

 

If you'd like to see this in action (in real-time), I have posted a video of the demonstration here.

 

Hopefully I will follow this blog up shortly with a single file restore for Exchange.

Outcomes