Comprehensive data protection for all workloads
Post Reply
trickybits
Novice
Posts: 8
Liked: never
Joined: Oct 06, 2010 8:30 pm
Full Name: Jakob
Contact:

Replication question

Post by trickybits »

Hi Veeam folks,
First of all I'm extremely happy with Veeam and it has saved us on a couple of occasions already.
Since I'm new to this I'd very much like for someone to explain a couple of things or point me in the right direction.

We have used replication to migrate VMs from one datastore to another (where vmotion is not available). Manually removed the replica from inventory, moved it out from the VeeamBackup folder to the datastore root, and then registered the VM. So basically we've turned replicas into active VMs. I'm not sure if this is the feng shui way of doing things.

Typically, turning a replica into an active VM in this fashion leaves the VM folder packed with files like .vbk and .vrb. So, as it's technically no longer a replica, can the vbk and vrb's be removed?
There's also an exact copy of the vmname.vmdk file called vmname_working.vmdk which I'm not sure why it exists or even if it's Veeam that created it. What is this file and once again, can this file be removed?

Thanks in advance
Gostev
Chief Product Officer
Posts: 31766
Liked: 7266 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Replication question

Post by Gostev »

Hello, yes you can remove .vbk and .vrb files - these are no longer needed if your VM is no longer a part of replication job. I would not recommend deleting _working.vmdk file though. This is auxilary file Veeam replication engine uses, so it is no longer needed. Essentially, it is a descriptor file pointing to an existing VMDK (nevermind the displayed size, it is really small - datastore browser simply shows the size of VMDK this descriptor point to). I am afraid that deleting this file through datastore browser will drag actual flat VMDK along. I have already asked devs/QC to determine and test safe way of removing this file, but they are very busy right now pushing v5 out, so this research would have to wait a little. So for now, it would be safer to just leave it this file alone there - again, it does not eat any disk space despite of what datastore browser shows. Thanks!
trickybits
Novice
Posts: 8
Liked: never
Joined: Oct 06, 2010 8:30 pm
Full Name: Jakob
Contact:

Re: Replication question

Post by trickybits »

Thanks for these answers Gostev,
I can check on a lab-VM to see how the VM is affected by removing _working.vmdk in the datastore browser.
trickybits
Novice
Posts: 8
Liked: never
Joined: Oct 06, 2010 8:30 pm
Full Name: Jakob
Contact:

Re: Replication question

Post by trickybits »

yep, removing the vmname_working.vmdk in the datastore browser will also delete the vmname.vmdk
wdbarker3
Novice
Posts: 9
Liked: never
Joined: Jan 28, 2011 11:48 pm
Full Name: Dan Barker
Contact:

Re: Replication question

Post by wdbarker3 »

You can remove the _working.vmdk, but NOT using the VI Client. Just use the console, cd to /vmfs/volumes/<DATASTORENAME>/<FOLDERNAME> and do a ls -als to see what's there. If you remove using "vmkfstools -U machinename_working.vmdk", you will kill the real file, just as the VI Client would. However, if you "rm machinename_working.vmdk", you will delete only the Veeam file, and not the underlying machinename-flat.vmdk, on which the VM relies. Do a "cat machinename_working.vmdk" and compare it to a cat "machinename.vmdk" to see they both refer to the same underlying flat file. The working file uses a single head and a bazillion cylinders to simplify math, I guess. The base vmdk file uses a more realistic number of cylinders and heads.
Vitaliy S.
VP, Product Management
Posts: 27356
Liked: 2788 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: Replication question

Post by Vitaliy S. »

Dan, thanks for sharing this info.
eliseocd
Lurker
Posts: 1
Liked: never
Joined: Jul 08, 2011 4:30 pm
Full Name: Juan Eliseo Carrasco Diaz
Contact:

Re: Replication question

Post by eliseocd »

Another way to remove the _working.vmdk file is going to <DATASTORENAME>/<FOLDERNAME> from Veeam Backup itself. Before doing that you must add the ESX servers (or VCenter) to Veeam.

From here you can edit _working.vmdk, rename the line with machinename-flat.vmdk to machinename2-flat.vmdk or whatever. Save changes, and now you can remove safely the _working.vmdk file.

Anyway, I think that Veeam Backup should have the option to do that a replicate VM can be handled from VI Client definitely, extracting it from VeeamBackup folder and so on.
Gostev
Chief Product Officer
Posts: 31766
Liked: 7266 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Replication question

Post by Gostev »

And we think so too :)
Post Reply

Who is online

Users browsing this forum: Google [Bot], Semrush [Bot] and 30 guests