Simple Disaster Recovery Strategy - brute force copy of VMDK's?

[booradley201110]

Hi all -- I hope this isn't too ignorant a question, but I'm looking for thoughts on the most simple and foolproof strategy for backing up and recovering my environment. I have read about vDP and third party solutions, but I think they're overkill for my situation, which is this:

I am responsible for a small test datacenter that has 15 esxi+ 4.1 hosts, and about 75 VM's. Of the 75 VM's there are only about 10 that I simply can't lose: the vCenter and AD VM's and ~8 other servers that can't be easily recreated. The rest of the VM's I can easily provision again, provided I can restore an environment with the 10 previously mentioned VM's....

Right now, the environment is connected to an IBM DS5020 SAN storage device running 8 x 2TB LUNs. Two of the LUNs are empty, and I've been making copies of the VMDK folders of the important VM's in the 'browse datastore' view, and dragging them into these empty LUN's. I ran a simple test by deleting a source VM, then going to the copy and selecting 'add to inventory' and poof -- that VM is recreated....But is this a sufficient strategy if I get hit by a bus?

In other words, suppose I have copied my 10 'must-keep' VM's to a spare LUN, by copying the folders. One day the ESXi hosts that ran these 10 VM's fry in some weird power surge. Would someone be able to completely restore the environment by logging directly onto one of the remaining ESXi hosts, browing the datastore, and adding the backup's back to the inventory?  How would the restored vCenter server be able to reconcile any environmental changes if they occured past the date of the original backup (for example, vm reconfiguration or deletion).?

Also, if this is a valid backup/restore strategy in the case of absolute disaster, is there any advantage to copying the folder containing the vmdk data as opposed to selecting the VM I want to backup and choosing "clone" (but not powering it up, of course)?

Thanks!!

[SG1234]

how do we make sure that the copies are crash consistent - for example the disks may be busy while you are copying the data and the resultant data from backups may not be reusable ...

So I would much rather choose the clone method over the normal copy or if not create snapshot  and then a clone from it and the copy

does the SAN provide any good DR solutions?

HTH

~Sai Garimella

[booradley201110]

That's a good point on the clones -- I've been temporarily powering off the VM's I wish to copy to assure integrity. when I copy them. I suppose the SAN could be another point of failure, and I could copy the backups elsewhere, but I'm less concerned with where the copies ultimately live but rather: what happens when I restore them -- especially the VCenter and AD VM's. Will they be able to transparently handle being restored to a different host that might have different processor specs, MAC addresses on the NIC's, etc?

[William22]

Hi

Welcome to the communities.

In this case you need multiple copy of backup on different location ,

Out side office

"With normal actions you get normal   results."

[SG1234]

interesting - how about doing a trial run and see what issues come up?

[booradley201110]

Yes, I will try to find a day when I can power off the vcenter and AD guests, then try restoring a cloned backup to an empty ESXi host server. If nothing else, I should probably try to keep regular backups of the SQL db, as well.  Thx