VM Copy vs Replication

[bbeavis]

I believe I understand the differences between VM Copy job and Replication job. I'm thinking of switching from Replicating to simply copying.

First, I don't need replica history. I currently replicate between our two ESX vSphere 4 systems. I also have a VM Copy job which writes to a USB drive plugged into our vCenter system (it is Truecrypt encrypted). We rotate out the USB drive weekly and I run the VM Copy nightly. The VM Copy uses the API and block changes so the process is quick.

Second, with no failback, replication seems incomplete. The process of recovery is "cloudy". For example, I currently need to take Server1 down for maintenance (HP needs to run diags on it). If I replicate the production VMs to Server2, they generally come up without a hitch. Once Server1 is ready, I want to move all the VMs to it and then perform ESX patching on Server2. I definitely don't want to use Undo Failover, that simply deletes the running state and restores to snapshot. A very, very bad thing for production VMs. As mentioned, there is not failback. So the process, which is not clearly documented, is a pain to reverse. If I simply do a pause, VM copy, startup, then I can do a VM move with minimal down time. I suppose I can use our SAN device, although it is a very basic SAN and has limited snapshoting and is not generally suppported with "normal" SAN features. It is an entry-level SAN at best.

So. If I VM Copy, then manage which system is "King" I should avoid replication headaches. The VMs are ready to go and there is no failover state to worry about. Keep in mind, I have a small 3 system structure for VMs and 3 bare metal utility servers, roughly. So I'm thinking in my scenario, VM Copy's simplicity is better than Replication's manageability.

What do others do? What are the reasons for using one over the other? My goal here isn't to answer a specific question, but to discuss the merits of each and expand everyone's overall understanding.

[Gostev]

Couple of things to consider:
1. VM Copy copies the whole VM each time, instead of changes only, so it is definitely not as effective as replication.
2. Re: replication history, without maintaining it you are risking with not being able to restore from software corruption or virus (as corrupted stated will be replicated to the target as well, before you notice the corruption).

[bbeavis]

Is it copying the whole VM? I am using the vStorage API and it does say that it is using changed block tracking. Which leads me to a question. I have USB devices 1-5 (we'll call them USB1-USB5). I mount them under Truecrypt as Z:. I copy the VMs to Z:\VMCopy\<VM Name>. If there is no "base" VM, then it does drop the VM in place. If there is one already there, where does it get the information about changed blocks? Rsync does a sliding checksum type thing. Does the vStorage API do some form of live compare? Or does it keep a record of changes, and if so how does it determine the point in time. If I put in USB1 blank and do a full VM Copy on Monday. Then USB2 on Tuesday and do a Full VM Copy. What is the result of putting USB1 in on Wednesday? Does the VM Copy job delete whatever is there and do a full copy? Does it apply block changes from Tuesday, skipping the block changes that occured between Monday's and Tuesday's Copy? Does it do some comparision to simply bring whatever base (Monday's in this case) up to current, similar to rsync?

This could apply just as well to Replication if you replicated to removable media.

BTW, that is my task. Backup VMs to removeable media, with DR in mind. I don't want too many steps involve in either the Backup or Restoration process. In DR, I just spin up an ESX system, copy over the VMs, and power them up. No third party apps needed. However, if the VM Copy does not work (I have a large backup window, so even full copying is OK), I will need to change. And we do run 3 days of DR testing every year, this method is untested.

[Vitaliy S.]

Hello,

Actually, when you run a Copy VM job for the second time, it again copies the entire VM to your destination storage, overwriting the existing files. As for the message you see about change block tracking that is enabled, it looks like a cosmetic bug, I've already submitted this request to our internal bug tracking system, thank you for your feedback.

So answering your questions, the information about changed blocks is only used with Backup/Replication jobs, this information is received from VMware, let me try to explain how it works: when you first do your backup/replica job we recive a Change ID for your VMs, this ID is saved, cause it's responsible for tracking all the changes, it is some kind of a flag, so when you run your job for the second time, we ask VMware about all the changes that happened starting from the Change ID that we've recieved previously, and as we get the information about all changed blocks starting from that Change ID stamp, all the changed data is being transmitted to your backup storage.

So returning to your example, if you use a Monday USB 1 drive on Wednesday there are two possible scenarios depending on the job mode you've chosen: for VM Copy - it will re-write the existing VM doing a Full VM copy once again, however, If you used Backup type job, then the job would have transmitted only the changes that happened from Monday Change ID flag, these changes would also cover changed blocks from Tuesday.

Hope my explanation wasn't too complicated

As for you task, actually you do not need Veeam Backup and Replication software to do a restore, you can just use Extract utility, there is a full usage description at our website User Guide (page 86), on the other hand you can continue using your strategy with just VM Copy, but in this case as Anton has already mentioned there is a risk of copying corrupted VMs to the USB drive.

Thank you!

[bbeavis]

You example is useful. How many Change IDs does VMware keep? Does it do a full copy if not found? As an example, say you have a Backup/Replica from a year ago, will it still only do just changes?

So, VM Copy will work with not protection and take longer. I am inferring that Backup to an external device/tape would be the recommended method, even over Replication. I'll certainly look into that further.

I'm still having a hang up on no failback in Replication. I find my self breaking the replication cycle and causing issues and having to recreate jobs. It seems to get messy. Take this example, Server1 and Server2 are vSphere and Windows1 is a VM running on Server1. There is a scheduled replication job from Server1 to Server2 creating Windows1_replica on Server2. Server1 is offline (crashes, down for maintenance, etc). I have two choices, failover the replica vm or just start it. Now fast forward a week or two, Windows1_replica has been running the whole time. Let's say it is a file server. If I do Undo Failover, then every file change done over the week or two is simply gone. I've tested this, and their is definitely not enough warning messages. So what is the recommended steps to restore things the way they were? How do I copy the changes from the replica to the production VM and then restore the replica function. Or, what if I decide to leave the Windows1 on Server2 and then have Server1 hold the replica?

Another issue I've run into is multiple VMs in a single replication job. The process works, but the problem is if I want to run replication on a single VM. The jobs run all or nothing. If you create a second job for just one VM, then it has issues. A minor issue and I'd bet it has to do with keeping track of things.

[Vitaliy S.]

I believe, it will still use a change block functionality even assuming the year is a long period.

Well... it is you to decide which VMs should be backed up and which one should be replicated, it all depends on your internal backup policy. By the way, here is the good topic that shows some differences between backup and replication, just in case. Also you can do some search on the forums for the examples of using backup or replica strategy from other our customers.

As for the failback, right now the exact thing that fits your scenario may be the VM Copy feature, you can use this to move your VM without powering down to the primary ESX host that was originally used for that VM, also keep in mind that you may configure a replication job back to the original host.

Basically, if you place some VMs within one job, yes, they all will be replicated as soon as you start the job, as for the issues you see replicating one VM, you can open a support ticket with us to troubleshoot and resolve your issue.

[bbeavis]

Obviously for live migration it is best to spend the money and do vmotion. One thing I have not tested is replicating a VM when powered off. Does the replication work correctly or is the VM expected to be powered on?

If it is valid, then moving a VM from on server to another would be

1. cleanly shutdown VM
2. manually run a replication to update the replica
3. failover or startup the replica

What are the steps to reverse? Would they be the same?

Also, VM Copy only gets what I need, Replication leaves extra files. If I break replication and make the VM permanent, what files are safe/should be removed?

It seems to me Replication is probably the best way to move VM's between datastores and VM Copy for datastore to filesystem.

Is replication hard code to the folder scheme it uses in the datastore, both the base and the VM names?

[Vitaliy S.]

Yes, surely, replication works correctly when the VM is powered off. Of course, you can spend money and do vmotion, VM Hot Copy is just another useful option for your convenience.

As for the reverse order, yes, you got it right, you can perform the same steps to move the VM back to it's original place.

Replication's extra files are your rollbacks, if you want to make this VM primary and you may delete VBK and VRB files.

And yes, the folder scheme is hard coded, thought you can specify the VM name by yourself while configuring your job settings.

[bbeavis]

To do vmotion right, we'd need to buy more stuff all around (hardware and software) and the reality is that constant uptime has a price that the decision makers don't want to pay for at this time. Only maybe 1 or 2 VMs being down for more than 15 minutes would be an issue. Heck, our CRM system crashed (Veeam VM Copy started a snapshot which failed and powered down the VM) and I rebooted it immediately. No one noticed. Sometimes you need to sacrifice features in order to get a project approved. Spending and addition $50k+ wasn't even worth trying to justify. When we renew software and upgrade the SAN, we'll try to slip it in.

So since the Folder scheme is hard coded, I guess my VMs will probably live in there. At least eventually, as the get passed back and forth.

[eason]

[merged into existing discussion]

After reading the Veeam Backup & Replication 5 Help and the User Guide, I still don't understand the difference between replicating virtual machines and copying Virtual Machines, can sb explain or take a circumstance for example? thanks for help.