Restoring VMFS Luns from Tape (DR Scenario)

[ploughingon]

Hi,

I can think of several forums to ask this question , this looks like a good place to start.

We have several vmfs luns hosted on our san , we use iscsi to connect to them.

Our backup solution has no problem backing up the lun or restoring if its just restoring to a working data store, the problem have has arisen when testing a "bare metal" DR type test ie when restoring to an alternative location.

When i restore the lun and map the initiator to it, the esx hosts see the lun as an unformatted drive, rather than an existing datastore.

Has anyone had a similar problem or can tell me what I'm missing

Thanks for reading.

[foofighter26]

Hi,

Take a look at this:

http://www.vmware.com/pdf/disaster_recovery.pdf

regards,

Paul

[ploughingon]

Thanks for that but its not quite what I'm after. I have a strategy that i would like to use, but its while testing it that I came accross this roadblock.

I Know the Lun i have on tape is a good back up , when i restore it into its original location and bring the Lun back online, ESX see's it fine, the problem I have is if i was restoring it in the DR Data Centre, ESX is gonna want to format it, which kinda misses the point.

Any ideas or suggestions apreciated.

Thanks

[bertdb]

so you restore the contents of a LUN, show it to the ESX, then rescan the iSCSI adapter (or the whole SAN) ?

That should really work. Do take care that something that was LUN 26, gets restored and shown as LUN 26. If you show the restored LUN as some other LUN number (not 26), the ESX will detect it as being a snapshot.

[ploughingon]

thats close to it but its not the contents of the lun thats restored , the tape drive on the san just see's a file called for example vmfs1.lun and restores that.

I had thought about the Lun ID being a problem , but as I'm essentially restoring to fresh install of esx, i figured it should pick up the LUN ID that was previoulsy assigned by the SAN , but i will go look at that again.

[bertdb]

restoring vmfs1.lun amounts to the same thing, vmfs1.lun contains everything the LUN contains, doesn't it ?

how your disk array represents vmfs1.lun to the iSCSI, that's what defines which LUN ID the ESX will see. The thing is, the ESX will notice that the VMFS unique ID doesn't match the LUN ID if it's different from the original LUN ID on which the VMFS was created.

That will happen even if you reinstall the ESX, any ESX that sees that volume would notice the discrepancy between VMFS ID and LUN ID, and would trigger the snapshot detection algorithm.

[ploughingon]

Yeah sorry , the lun ofc contains everything, i misinterpreted your answer and tried to over qualify the scenario.

...

So if i make sure that the Lun has the same ID as when it was originally presented that should sort it?

[bertdb]

having the same LUN ID will avoid one potential problem. Whether that is your (and your only) problem, further testing will tell. Good luck.

[ploughingon]

well, if anyones interested, I've just created ...destroyed and restored (from tape) a vmfs lun . Using the same Lun ID's and names wherever possible, and v center still wants to format the new drive.

think its time to call VM Support direct to find out what I am missing

[bertdb]

so after a rescan, your ESX sees the new LUN, but not the VMFS that was restored on that LUN. Apparently, there's something wrong with the data on that LUN. VMware support will ask you to run esxcfg-vmhbadevs and fdisk -l on the resulting /dev/sdX mapping to look at the partition table. If the partition table is not there correctly, that's a clear indication that something goes wrong with the restore process.

[ploughingon]

i thought I'd better post the follow up solution..

It turns out that I needed to set the LVM.EnableResignature option to 1 which can be done in the advanced config bit of VI Client.

All sorted now.

Thanks all for responses