Problem with backup copy.

[JosueM]

Good day everyone.

I few days ago I started to use backup copy instead of replication, before today all was working as expected but this morning I found thins pretty weird. The backup copy jobs were moving just the data that haven changed in the day.

This is backup job for a win2k3 fileserver runing once per day reverse incremental, last backup was ok today around 2:00 am procesed 825 GB read 21 GB and transfered 14 GB.

The problem is the copy backup started about 3:00am and is still running after 6 hours processed 135 GB read 135 GB and transfered 119 GB.

I wonder why the backup copy is moving all the data again ?

[Gostev]

Hello. Unlikely, as Backup Copy jobs are forever incremental, they don't have a concept of "full backup". Probably, there were some significant changes made to the contents of virtual disks of the VM in question. Debug logs may be able to tell more, so feel free to open a support call, if you want to troubleshoot this behavior. Thanks!

[JosueM]

Hello Gostev,

That's why this is weird cuz backup job trasfered only 14 GB , then the logic tells me the backup copy job should only trasnfered about the same amount of data. In fact today I notice the backup copy job did failed cuz it filled up the remote backup repositoy.

Support case is 00679734

[JosueM]

In fact the support reply got me confused, I believed the it was not that way.

"Thank you for opening a case with us. Our best practice for backup copy is to have the source backup running in forward incremental mode. The reason for this is that the backup copy job is always going to read the data from the most recent backup file; in the case of reversed incremental, that file will always be a full backup, so there will be more data to process than if it were only an incremental file."

[JosueM]

I'm posting some screenshots to brief more:

Backup job (SOURCE FOR BACKUP COPY): started 2:00am and finished succesfuly at 2:29am



Backup copy started at 3:00am and data trasnfered clearly more than source backup.

[foggy]

Is it a daily backup copy job?

Regarding support tech reply, I also cannot fully agree on the reasoning. Basically, forward incremental could indeed be a bit faster source for the backup copy, as random reading from heavily fragmented full reversed incremental VBK file can certainly be slower than just sequentially reading VIB file. However, I would not call this our best practice, since with pretty fast primary backup storage, this does not make much difference and the more so, does not affect the amount of data to be transferred in any way.

[JosueM]

Hello Foggy,

Right, this is a backup that runs once per day. I also believed that indepent from source backup method it should not affect the amount of data to be transferred.

In fact there is another backup job and backup copy for another VM that is running the same settings and is working fine.

I will make a new initialization for this failing job on the remote site.

[veremin]

Is it Direct or WAN Accelerated backup copy job? Also, can you tell whether the previous restore point created by backup copy job is incomplete state by any chance? Thanks.

[JosueM]

Hello Eremin,

We don't have WAN accelerator, the transfer is direct. Yes previous restore point is incomplete.

Thanks.

[veremin]

Yes previous restore point is incomplete.

That explains why a backup copy job transferred more data, than a backup job did. The previous restore point had been incomplete, meaning, during subsequent run the backup cop job copied not only current changes, but also the data it had been able to copy before. Thanks.

[JosueM]

Thanks for you quickly support, that makes sense. That's why I rather to post in the forums before opening support tickets.

[veremin]

You're welcome. We require support ticket ID for posting about technical issues, because addressing problem via forum correspondence might take a while, until the resolution is found (if ever). Also, most of the technical issues require deep log analysis and the team behind this community cannot assist you with that. Thanks.