Backup Copy Job Source - Incremental or Reverse Incremental?

[mattpayne59]

I have searched for this topic on the forums and I see multiple posts that for a backup copy job it doesnt make any difference what the source type is currently set to. Support just told me that it will take a lot longer and create more traffic over the WAN using reverse incremental on the source instead of forward incremental. Is there any truth to this and why hasnt it been mentioned before?

[dellock6]

To be honest, is the first time I hear such a statement... does not sound correct to me.
At the end, Backup Copy reads changed blocks, check both wan accelerators if changed blocks are already there, and in case copies them into the target. Blocks inside a VBK files are the same regardless if you created VBK via reversed or forward. If it's not, it would be something totally new to me, and a huge surprise...

Luca.

[Vitaliy S.]

Hello Matt,

Can you please tell me your case ID where you have discussed it with the engineer?

Backup copy jobs do not copy files, they synthetically create new backup files based on the VMs you have added to the job. It doesn't matter what source backup jobs are set to: forward or reversed incremental mode. I believe there was some kind of misunderstanding between you and the support engineer.

Thank you!

[Gostev]

I guess I can see the point behind support engineer's statement. Reading a restore point from some terribly fragmented reversed incremental VBK file can certainly be much slower than reading forward incremental VIB file, especially if the primary backup storage is nothing fancy...

However, in more typical scenario and decent backup storage, the backup mode does should not make much difference. I for one would not worry about that.

[mattpayne59]

We are only going to have about 7 copies locally so i cant see how that would be a problem. I believe it was support ticket 00462168.

I am still a bit confused on how this works. I seeded a backup copy job to my remote site by manually copying the vbk from the reverse incremental and then importing and mapping it to the copy job. When I kicked off the backup copy it seemed to be creating a ton of traffic... It was running for a few days and had transferred 50GB of data and I think the total changes for the day were around 20GB. Before I upgraded to v7, I had a backup job with the same VM running to my remote site. This same job was taking a few hours or so to run. I assume this isnt the way it is supposed to work? Should a backup copy job over the wire take more or less time than the actual backup job itself would have taken the way I had it set up in v6?

[Gostev]

Should a backup copy job over the wire take more or less time than the actual backup job itself would have taken the way I had it set up in v6?

Actually, slightly faster due to not having to prepare VM for backup, or wait for VM snapshot to be removed afterwards.

[mattpayne59]

And my steps seemed accurate? Copy the vbk and vbm file, import the job and map it to the copy job and then I should be good to go? I am going to try this process again tomorrow.

[tsightler]

Don't preform a manual import import, just drop it in the remote repository and rescan the repository which should make it show up as imported. Then create a new Backup Copy job and map it to the imported backup. That should do it. Are you using the WAN acceleration feature or just direct mode for the Backup Copy?

[mattpayne59]

That is actually what I did last time... Rescanned it and it showed up in the import folder. I am using the WAN acceleration feature.

[Gostev]

My "slightly faster" answer assumed you are talking about Direct Mode, as this is what you can compare with remote backup job. WAN acceleration is totally different story.

With WAN Acceleration, faster or slower will depend on your available WAN bandwidth, and WAN Accelerators performance (mainly, target WAN accelerator's cache). Generally speaking, WAN accelerated transfers can take MUCH longer comparing to Direct Mode if you have fast and empty WAN link. However, they use at least 10x less traffic, which makes them finish much faster on slow or busy WAN link with little bandwidth available.

[mattpayne59]

I am trying to backup every day to my remote location. I have a 100MB fiber link at my main location and I was using 27/7 cable which I actually upgraded to 100/20 which is getting installed tomorrow. So I should just use direct mode to get the best performance and forget about WAN acceleration?

[veremin]

Typically, WAN accelerators should be able to saturate up to 50-100 Mbps (with SSD cache), with effective bandwidth being 15-20x of that number. You can test both methods and see what best fits your requirements with the hardware you are able to dedicate to WAN accelerators.

Thanks.

[mattpayne59]

Ok... I assume I can switch back and forth between direct and WAN acceleration as I do my testing? I understand it will probably have to rebuild the cache but that wont have any impact on the actual jobs right?

[veremin]

You can start with direct mode and, then, switch to WAN Accelerator to see what method gives you faster performance. Switching between modes shouldn’t cause any issues.

Thanks.

[mattpayne59]

This is now the second time I have done this process and I got the same error message again:

Disk Server-flat.vmdk is corrupt, possible reason: Storage I/O issue

I get this error on the copy job when the backup file verification is running. I ran the veeam.backup.validator before I copied the files off and it didnt show any corruption. So does this process just not work?

[Vitaliy S.]

Switching between transfer modes shouldn't cause this error message. Do you have a support case opened on this issue? What is the case ID?

[mattpayne59]

00462390 I think was the corruption ticket. There was originally some corruption in the source. I redid it twice now and I am getting this error message. I havent called back support because they basically just said it is your storage problem and didn't really have much else to say.

[mattpayne59]

And this isnt a switch between transfer modes. I copied the vbm and vbk, took them offsite, copy them to the repository and rescanned it. Then I kicked off the backup copy job for the first time with the new vbk and after about 45 minutes this came up and stopped the job.