SAN Based Backup Performed, Restore Fails - VM Based
So I finally got my VM backups looking good. File based restores are working well with the GRE inside of the vSphere client. My next test was to try out a full VM restore. All of my backups are SAN based backups. They go over our iSCSI network and then traverse our Backup network. I performed the restore and everything seemed to go ok. I see the vmdk files. I see the vmx file. The VMX file looks good. The VMDK is the appropriate size 60 gigs provisioned, 24 gigs consumed.
So here's the problem: I go to power on the VM and the disks are invalid. The VM powers up, but the virtual disks are not seen by the VM's bios. I went ahead and mounted the VMDK files to a slave Virtual Machine and I was surprised to see that the disks were coming up un-initialized. What's up with that?
I have an open case with the Data Protector group.
So reading through some forum posts (that I had to find using Google and not the built in search feature), I read a post where someone suggested doing an NBD restore... I forced my Data Protector to do the restore via NBD and it appear to work but this is not desireable. Why is this a thing?
It is limitation of DP , due to scsi address changed & it will not refreshed during restore session , so allways restore by using NBD mode .
Plz assign Kudo
I am not sure if you understand me properly.
I am actually forcing an NBD restore. When I force the NBD restore, the VM works properly. By default, if I do not change anything, DP attempts to do a SAN based restore, but the SAN based restore does not work. That is to say, the SAN based restore completes and is successful as reported by DP, however, the VM that is restored is not functional.
I am starting to make some headway with DP support. I will post if I reach a resolution.
Just catching up on the forum right now (I don't get a lot of replies from this group so I do not frequent this forum set). Ok so here's the deal:
It was my interpretation that DP instantiates the write back to the data stores through the ESX servers. That is to say, that DP says ok, I am going to do this restore, but I am going to use the ESXi server to write to the datastore. This is not how DP works. A long time ago, in a galaxy far, far away... I decided that to protect against others doing something stupid, like mounting my VMFS stores and formating them on the DP server, I would deliver the LUNs to the DP server in a read only format. This is essentially what creates the problem. When the LUN is in a read only format, of course DP cannot write back any of the virtual machine's data to this store. Under my assumptions previously, I thought that DP instantiated the write back feature through the ESXi servers which, naturally, have read and write abilities to the LUNs. Obviously, when DP is unable to write using SAN transport, it goes down the list and of course NBD is the next delivery method it's able to use.
To correct the issue (or realistically my behavior), I created a VMFS volume that the DP server has read/write permissions to. During restore processes, I have trained myself to target this VMFS volume, power on the Virtual Machine to be sure everything is ok, and finally migrate the VM to a permanent place on our regular data stores.
Essentially, the issue was user error however, it's a DP issue that reports the restore as "successful" when really it's not. DP needs to be updated to reflect a restore failure in this instance.