Restoring VM to NEW location also deletes original?

[YoMarK]

Today I created an issue restoring multiple VM's from backup(actually to create a temporary test environment)

I've used the option "Restore to a new location, or with different settings" . The restore location was a different geographical location , different vcenter datacenter, different ESX server and different storage.
The restore started and it went fine. The VM's where restored to the new ESX servers. But then I saw that the original VM's where powered of and deleted. No warning, nothing.
I've done similar things multiple times already, and never had problems. It's worth noting that the other times I did this I probably rename the VM's, and this time I didn't. However, having the same VM name on another Vmware Datacenter is absolutely fine in Vmware vpshere.

Now: I've logged a support case(# 01256668) for this . Long story short: this is "by design".
Really?

It's not needed for VMware(same name different datacenter is perfectly fine), it's not needed for the storage(filename issues) as it is on different storage, it's not needed for ESX. Actually the name is not important, at all, in my opinion as all the VM's are referenced by GUID. SO There is absolutely NO technical reason to delete the original VM. I'n my opinion there is no logic in this as well.

Now if Veeam still thinks it's the right thing to do, then a WARNING should be very helpful. Also in the manual there is no indication that it's going to delete the original when selecting a NEW location: http://helpcenter.veeam.com/backup/80/v ... overy.html

I think this is so stupid that I question the person handling this case telling the truth. That's why I created this thread.

My questions:
- So it's not possible to restore VM's to another separate location without destroying production, UNLESS you do not forget to give every single VM in the job another name?
- Is it logical that the name being the same(although perfectly fine in Vmware) should be the only reason to delete the original with any further user interaction.
- Do you think, as I am, that this "design" is flawed(or at least need refinement such as a big warning and/or a proper manual mention)?

[YoMarK]

The thing is also....I've done so many restores for tests and things like that(probably giving them a proper other name), that I wasn't expecting something like this at all.

[foggy]

Mark, have you specified different location for VM configuration file during restore?

[YoMarK]

Foggy: Thanks for responding!
Yes, completely different Fysical datacenter/Vmware datacenter/ESX host/storage.
(Freshly installed ESX host with local storage)

Edit: complete logs for the restore are in the support case.

I'm no expert on Veeam logfiles, but there are references in there with:
- the source "original" hosts esxpabiestxx with original "datastores" esxpabiestxx-local
- the target "new" restore host esxpahaarenxx with new datastore esxpahaarenxx-local
- deleting the, as it's called there "old" VM's on the source host.

Did a sort of check/test a few minutes ago, just pulling VM's from backup, and put it on a completely new location(only thing that's the same is the vCenter server and the display name of the VM), and not a single warning is given to me that it's going to delete the original source.

I think more and more that this is a major bug, and it's not "by design" at all.

[YoMarK]

FYI: If you mean I specifically changed the VMX file(config files) location: It was a multiple VM restore, changing host, ResourcePool, Datastore and Folder.
The File location of the VM configuration files then defaults to the first datastore on the new server, I did not change that specifically on the "datastore" page of the wizard as it was fine.

[YoMarK]

Installed the latest update, and this fixes the issue.
So luckily this "deleting the original" behavior was not by design.

[Delo123]

Hi Mark,

which update was that? This Sound scary and i am not Aware of any "new" Veeam updates. You are on 8? Update 3 was the update?

[alanbolte]

If this was the problem I think it is, it was resolved in Update 2a.

[mkaec]

Wow! That is scary. I just did a restore to a different location the other day to test something. Thank goodness we are on update 3.

[adrianmejia]

Hi everyone,
It seems that the first version of 9.5 has the problem, I am looking for the complete release notes for SP1 o SP2 to know if there mention something like this.

[foggy]

Hi Adrian, do you mean the issue is back in Veeam B&R v9.5? This thread was discussing v9 and its update 2a issued more than a year ago...

[utixo]

I confirm the problem is there again in version 9.5 and it's crazy ! if you restore a VM in a totally different location different datastore different all but same name the original gets turned OFF and deleted. very scary !

[veremin]

What's your support ticket number? Thanks.

[foggy]

Also, are you restoring to a completely different virtual environment (different vCenter)? Otherwise, the behavior is expected, since you cannot have two VMs with similar name under the same vCenter and Veeam B&R should warn you twice in restore wizard that the original VM will be deleted.

[jprovost]

Veeam Backup & Replication Version 9.5.0.711

I lived the same problem at my job. I started to use Veeam in January, I had no problem at all to create backup and restore in the original point or other location until those next events:

- Friday, June 2nd I did exactly the same procedure as the previous weeks. (Procedure that I use since January, without any issue.)
- Each Friday & Saturday I make a backup of all the VM of the company to a storage unit. (9 VM's to back up, 4 are done on Friday, 5 are done Saturday)

-Monday, June 5th in the morning, I toke a look to all my backup files create by Veeam.
--I have a third server in the company dedicate especially for test purposes and to create new environment or development. This server has it's own NAS, NIC, Network and cannot interfere with the live environment of the company.
--Veeam is installed on my computer at work. To back up or restore VM, I configure Veeam to access the vCenter.
--So, Monday, June 5th, I did the same as the previous weeks, test my backup file by restoring to my test ESXi server and confirm that everything works properly. (I need to specify, everybody in the company are on their computer and work on the business ERP.) I start the VM restoration, after a few minutes, I received a lot of calls for "Server unavailable" and then I notice that the "live" VM was deleted. That MAJOR issues cause a downtime in the business for 1h (because it was the first time we had this situation, we searched for a reason, solution and why.), finally it was better to put it back the restore (backup in date of Friday, June 2nd) and put back on the server.
--All the week, I search for the cause of that situation.

- Friday, June 16th, the same procedure to back up VM's.
- Monday, June 19th in the morning, I start a restore from my backup files to the test server. Same problem happens again. With this situation, I started to search on Veeam web site for an explanation (alert, warning, procedure,etc.) but nothing is mentioned clearly. I finally found your post, with the exact issue.
-- From some reply in this post, it mentions that if we change the name of the VM (when we restore) it doesn't make this unbelievable delete without asking... But I tried today (I completely isolate my test server, install a new instance of Veeam Backup & Replication) and the problem happens 1 time on 3. The best way is to completely isolate your environment... what I want to say is:
* You have a Server A and Server B.
* I want to create a copy of a VM present on Server A to Server B.
* I backup VM on Server A to a storage unit.
* In my test environment, I use my new Veeam installation. The only connection I have to my live network is the storage unit.
* I start the restore to the test server.
* Everything works properly.

I printed the entire post and advertised all my colleagues in my department about the bug.

[Delo123]

So there is no warning at all that the original VM is deleted or is there a warning and you acknowledge that? Just to be sure it doesn't happen to someone else because until now i couldn't tell from any of your posts since i assume at all times you have both vcenters added to veeam (else it wouldn't be possible to delete anyway), also i could 't find if you really use 2 independant vcenters..

[YoMarK]

I do a lot of restores for testing/development purposes, and have not experienced this problem myself lately. Last week I restored more then 100 vm's for a disaster recovery test, and that all went fine, but I'm on 9.5.0.1038.
I would definitely make a support call for this, so they can review the log-files and pinpoint the problem.

[wuerzburger]

We ran in to the same problem.

Made a restore of our database server with other datastore and esx server specified, but forgot to set a new/other VM name.

Then our productive database server was shut down and deleted. Took us 2 days for recover to last state because of other problems with oracle restore.

It would be great if Veeam could implement a warning when a restore will lead to a deletion of a productive VM!!!

So far we removed the right to delete VMs from the veeam user in vcenter to avoid it happen again.

[troyvaerten]

Same issue here today.

Was seeding a job to our offsite data-center. Different Cluster and Different DataStores.

Started restoring files for 3 VM's and then just after the job started our production systems became unavailable. Stopped the job immediately after seeing the log files state the VM's were deleted which saved the 3rd VM from getting hosed.

I'm in the process of going through the user account settings that run the job to remove delete access from the service account. I have done this in the past to our other data-center without changing or appending the name, I have a VM right now named the same living on our production and backup data-centers.

Very frustrating. Please build in a fail-safe or acknowledgment to the product for deletes.

[Delo123]

Yes, an additional acknowledgment would be nice and needed on actual deletes, as it really isn't clear in todays "automation". Also an option to unregister the vms instead of deleting would be nice, so the user can delete themselves if they really want... (sometimes you would still like to access some data)

[pidthepiper]

So is this still an issue in the latest v9.5 ? I am getting a bit muddled reading through this post?

I need to restore a VM to a different location but dont want to kill the live one!

[oliverL]

Would be nice to know if this has been an configuration issue or if we need to go against the best-practice guide and remove the "delete file from Datastore" from the Veeam-vmWare-Service Account...
https://www.veeam.com/veeam_backup_9_0_ ... ons_pg.pdf