v6 recurring VM copy not overwriting previous copies

[Stefan74]

Hi,

since upgrading to v6, VM copy jobs do not overwrite previous copies of the same VM anymore.
Instead, a new folder is created for each copy job: <path_prefix>/<VMname>(vm-<ID>)_<NR>
<NR> increments upon each run of the VM copy job, thereby filling up the destination file system.
The v6 documentation states '... every new pass of a VM copy job will override an existing VM copy.' So it seems that the observed behaviour isn't intended.
Anybody encountered this issue also and has a workaround for it?

thanks
Stefan

[foggy]

Stefan, do you create a new VM copy job each time or have a job scheduled to run periodically?

[Stefan74]

Hi foggy,

it's a periodically scheduled job.
Destination storage is an NFS share mounted via a Linux box if that matters. The directories with the copied VM files are created with mode 777 by Veeam although the default umask for user root is 0022 on that box.

cheers
Stefan

[Gostev]

Our QC has confirmed - this was changed due to the move to the new architecture with backup repositories. We will make this optional in the next update.

[Stefan74]

Hi Gostev,

thanks for the quick response and clarification.

cheers
Stefan

[micwe]

same issue here
Gostev do you know when will be a fix for that problem ?

[Gostev]

It is tentatively planned for version 6.1 to be released in H1 2012.

[averylarry]

[merged]

My existing copy jobs are not overwriting anymore in v6. Is that by design?

[averylarry]

Not sure why I was merged into this thread. In v5, my copy jobs overwrote as expected by default. Now in v6, the copy job just creates a new folder over and over again --

the first run it creates the folder:
vmname(vm ID)
the next run it creates a new folder instead of re-using and overwriting the contents of the already existing folder:
vmname(vm ID)_1

I just wanted to know if it is supposed to have changed in v6, as I'm clearly seeing completely different behavior from v5 to v6. Perhaps I'm doing something wrong (since there are new options -- repository, UNC, local etc.).

[Gostev]

Indeed, guess the moderator did not realize that you were talking about VM copy, and not file copy. Was not me! But I fixed it now, and moved to the correct topic. Thanks.

[averylarry]

Oh snap! I even searched for it -- well, I think I did. Oops. At least (for me) it's not hard to schedule a small script that deletes the folders first.

[arsprod]

It is tentatively planned for version 6.1 to be released in H1 2012.

where would I find the option?

[foggy]

Default behavior was changed to overwriting VMs, so there is no such an option in user interface.

[arsprod]

OK, but the problem is the vm-id changes so it won't overwrite on the destination

[foggy]

That's actually not related to the behavior discussed in this thread, as the VM is obviously treated as a new one after ID change.

[arsprod]

That's actually not related to the behavior discussed in this thread, as the VM is obviously treated as a new one after ID change.

ok, so I need to run replicas without new vm-id so that when they're copied to dr site they overwrite the existing file. Is that do-able?

[foggy]

Mm.. not sure I fully understand what you're trying to achieve. What was the reason of VM ID change? Are we talking about replication or VM Copy jobs?

[arsprod]

Mm.. not sure I fully understand what you're trying to achieve. What was the reason of VM ID change? Are we talking about replication or VM Copy jobs?

I do separate replicas for each VM with 1 restore point - those get vm-copied to off site dr site. Each time I run replicas they get new vm-id so end up with multiple copies of VM at the dr site. Make sense?

[veremin]

As far as I can understand, there are several possible options in this case:

1) Put into use PowerShell script that will clear a given location and, then, initiate start of VM copy job.

2) Since most of the times replica VMs stays powered off, you can utilize files to copy job, instead of VM copy one, specifying VM files as a source for it. This scenario should guarantee that each files stored in remote location will be overwritten with the up-to-date ones.

3) Assuming that you also have local backups of these VMs, you can use new backup copy job, specifying VMs that have been backed up already as a source of the job and remote location as a target.

4) Use two replication jobs, instead of one, copying production VMs to two DR locations.

Thanks.

[foggy]

I do separate replicas for each VM with 1 restore point - those get vm-copied to off site dr site. Each time I run replicas they get new vm-id so end up with multiple copies of VM at the dr site. Make sense?

Still do not understand why VM IDs change during replication job runs (unless each time you remove replica VMs from the target host prior to running jobs).

[arsprod]

As far as I can understand, there are several possible options in this case:

2) Since most of the times replica VMs stays powered off, you can utilize files to copy job, instead of VM copy one, specifying VM files as a source for it. This scenario should guarantee that each files stored in remote location will be overwritten with the up-to-date ones.

Excellent idea - didn't realize file copies could be scheduled. Going to try some jobs, thanks!

[veremin]

You’re welcome. Should any additional help be needed, don’t hesitate to let us know. Thanks.