Friday, January 9, 2015

Restore Single Files - Nimble Snapshots is There Anything They Can't Do? Part II

Hi Friends,

Have you ever had a file share and someone deleted or corrupted one of your files?  Or maybe you accidentally did it?



















Normally this would be cause for great confusion, anger, sadness, more anger, colorful language, you get my point.  Well if you had your data on a Nimble Storage array with VMDK's and were performing snapshots, you'd be in luck my friend!  Today I'm going to show you how to restore single files from Nimble snapshots if the disk was attached through VMware using VMDK's.





















So here we can see our file that we want to keep.









Unfortunately, things happen and...


















Yep, you guessed it, our really important file is GONE!  Or is it?.....

With Nimble Storage you can take snapshots and even synchronize with VMware vCenter so your data is synchronized.  How cool is that?  Well, backups are only as good as the restore, so let's see how we restore our Really Important File.

In an earlier blog I showed you how to restore an entire volume and bring it back online in VMware vCenter, but what if new stuff has been written to this volume and I don't want to replace the whole thing?  What if I just want my really important file back?

This looks like a job for this guy!!




















Or Nimble Storage snapshots!

Since I couldn't get a hold of the flying bunny, here's how you do it with Nimble and VMware.

Remember, this is with VMware VMDK mounted storage, not direct connect.  There are different methods to use with direct connect which I won't go over right now.

Okay, head over to your Nimble Storage GUI, select the volume your really important file was on and click on the Snapshot tab.  Select the snapshot that has the data on it and click on the Clone button.  Give the volume a name and you're done!  Well, done on the Nimble side.  :-)  Take note of the time stamp, that's going to be really important in a little bit.





















Back on the Volumes page we can see our clone CIFS-Restore and we can see the parent is share2012-cifs4. 
























Excellent, we're ready to go to vCenter!













We're going to add this volume as a datastore.  There's the volume and we'll add it and give it a new signature so we can have both the original and the clone mounted at the same time.












































Okay, almost there!  Now let's add the datastore to a host.  What host do you ask?  Excellent question!  It's a good idea not to mount the volume on the same machine it came from?  Why?  Well we gave the disk a new signature at the VMware level, but the OS might still get confused since it has it's own disk signature at it's level.

Now that we have a host to mount the disk to, add it through vCenter as an existing virtual disk.




















Select the clone from the list of datastores and presto!


















Oh crap, which one do you use?  Remember I said to pay attention to the time?  Choose the file with the same time stamp.


















Outstanding!  We now have our volume mounted up to a Windows host.  Head over to the Windows host and look at the disks in computer management.  Mine was mounted up and ready to go!







Go to Windows Explorer and your really important file should be there!




























Until Next Time!
-Brain

5 comments:

  1. Yes, but now you have to clean it all up, in such a way as to avoid an APD condition on your host. That's why I don't like that sort of "file restore".

    ReplyDelete
  2. Or you could just use the Nimble vCenter plugin which automates most of the above steps

    ReplyDelete
  3. Excellent point regarding APD! Take a look at my new blog post using the Nimble VMware vCenter Plug-in.
    http://glicksgraymatter.blogspot.com/2015/01/update-restore-single-files-nimble.html

    ReplyDelete
  4. Be advised that selecting the vmdk based on the timestamp is incorrect. The correct vmdk, which has the writes quiesced and the its state is app-consistent not crash consistent is the base vmdk. The other 2 are delta disks with writes after vss has been triggered.

    Another thing is that you are having 2 extra vmdks because you are snapshotting a server guest. In case of windows desktop you will get only one. Still, the correct vmdk will be the base one.

    ReplyDelete
    Replies
    1. Adding to the above, in case of Server guest OS (starting with 2003) the correct vmdk is 00002. Not because it has the same time stamp (both 0001 and 0002 may have the same minute timestamp) but because of:
      http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2038831
      http://cormachogan.com/2015/03/31/vm-snapshots-with-vss-traditional-versus-vvols/
      and
      https://pubs.vmware.com/vsphere-55/index.jsp?topic=%2Fcom.vmware.vddk.pg.doc%2FvddkBkupVadp.9.6.html

      Delete