VMware Cloud Community
gheywood
Enthusiast
Enthusiast

Restoring a server on a replicated volume

Hello,

We have a VMware server stored on a few volumes on our Equallogic arrays, which are replicated across to our DR site (daily schedule, perhaps changing to weekly, keeping say 10 copies). For various reasons (well cost actually) we don’t include this in our regular backup regime but we would still like it protected.

If we need to restore the server (in the event of a user deleting a load of files for example), can someone help me with the process?

From what I understand, we would:

1)      On the DR site, clone a replica of the replicated volume and set it online.

2)      Set security to make this visible from the ESX hosts.

3)      On a VM at the DR site, select “add disk”, browse to the newly created replica, and add the disk from the original server.

4)      At that point we can verify the data and copy it back.

Does that sound right? We need to test it, but I want to be sure I am going down the right path...

Reply
0 Kudos
8 Replies
idle-jam
Immortal
Immortal

from 3 on wards, when you could see the vmfs just add register the VM, right click the .vmx file. then power it up and you're ready to copy the file back.

sketchy00
Hot Shot
Hot Shot

I touch on this process on my post about replication with EqualLogic arrays.

http://itforme.wordpress.com/2010/05/31/replication-with-an-equallogic-san-part-3/

Step by step, with pretty pictures and everything.

idle-jam
Immortal
Immortal

i find this useful too, thanks for posting Smiley Happy

Reply
0 Kudos
sketchy00
Hot Shot
Hot Shot

Great!

Reply
0 Kudos
gheywood
Enthusiast
Enthusiast

Thanks for the help guys.

Unfortunately, we are not using ASM because we store our system drives and data drives on different SAN volumes (so we can optimize replication), which means that we cannot protect them using ASM/VE.

Also, in terms of just re-registering the VM and starting it, I don't want to do that, because I will want to (potentially) have the original server still up and running (depending on the damage we are talking about here), so if I can connect the drive to a different server, I can just copy back the corrupt data without too much complication (I hope).

Some great information though!

Cheers

Reply
0 Kudos
sketchy00
Hot Shot
Hot Shot

Hello gheywood,

Even though the link I provided focused on ASM/VE and ASM/ME for protection (via replication) of the volumes, in the situations where you'd want to turn up the VM remotely to pull off your good files, the procedure should be the same as if you weren't using ASM/VE.

In cases where I've done what you've been desiring, I never had any problems with interference between the two systems, because they were on completely seperate networks.  It was reassuring to be able to temporarily turn up a clone of the system remotely, while knowing there was no way the cloned system could talk on the primary network.

You mentioned that you do not use ASM because you store your system drives and data drives on different SAN volumes to optimize replication.  If you don't mind, could you describe a little bit more about these systems?  The reason I ask is that all of my SQL, Exchange and flat-file storage servers always have the data on a different volumes, but I fully leverage ASM/ME and ASM/VE to protect these systems.  ASM/VE protecting the contents in the VMFS volumes (e.g.  the C: drives of each VM), and ASM/ME protecting the native guest attached volume inside of each VM.  This gives me fully quiesced, application aware snapshots and replicas.

Reply
0 Kudos
gheywood
Enthusiast
Enthusiast

Well, I suppose we could bring the server up at DR since it is a different subnet... It just won't see anything until reconfigured.

It sounds like you use drives connected via the iSCSI initiator? We don't. All our drives are done from within vSphere, basically because we can limit the total number of connections to our SAN (less servers connecting to less volumes), and also, we are using SRM, so it is a bit simpler to have vSphere handle all the drives during recovery. It also means that the VM's are effectively OS and role agnostic. We don't have to load and/or maintain any iSCSI initiator (Microsoft or other) or load any third party tools (the Equallogic HIT kit's). *Generally* it seems to make the system a little easier to manage while still providing acceptable performance.

Of course the downside is that the protection is "crash consistent", but it is still a step up from what we had before Smiley Happy

Reply
0 Kudos
sketchy00
Hot Shot
Hot Shot

Ah... I didn't realize you were using SRM.  That makes sense.  SRM users, as well as many who use some of the good commercial backup apps out there (Veeam, etc.) tend to do the same thing, as they rely on vcenter's API to orchestrate everything.  And if vcenter can't see it, vcenter cant control it.  Smiley Happy  I might be doing the same thing if I were using SRM.

Yeah, we use guest attached volumes via the guest initiator.  It took me a while to change my mindset where I was relinquishing vcenters ability to handle those volumes, but the outcome has been extremely good.  On those select VM's (SQL, Exchange, file storage), it expanded my abilities in a few different ways;  1.)  Increase the protection frequency of the changed data  (ASM/ME snaps and replicas are so easy to make and restore from, while minimizing interference during the snapshotting stage), and it gives me good visibility into the I/O of the services rendered.  It's also been kind of neat to utilize some of the HIT's tools, such as EQLXCP for offhost file copies.  Aside from that, all of my other VM's though are pretty traditional.

A million different ways to skin a cat, or something like that.  Good luck!

Reply
0 Kudos