Disk path has been changed since last transfer?

[mlinders]

On one of my larger VM's i'm getting this as a warning in the task log:
"Disk path has been changed since last transfer. Disk 'XXXXXXXXXXX_3.vmdk' will be transferred as full."

Since this VM has 2 different 600 GB disks, it's taking 5 hours to process this 1.2 TB of data. I'm really curious if someone can explain what the warning is telling me.

Regards,
Mark

[foggy]

Mark, haven't you recently migrated the disk or re-attached it to the VM by any chance?

[mlinders]

Hello Foggy,

There have been no changes to the virtual machine. I did change our Reversed Incremental back-up method to Forever Incremental. I checked back into the history and the moment we changed to Forever incremental this virtual machine was reading the disks as full. It is doing this every run now. So it's not recovering from this status.

Regards,
Mark

[foggy]

This is not expected. Unlike switching back from forward to reverse incremental, there is no need to create full backup. I recommend contacting support with this behavior.

[mlinders]

Case # 00683644

[y1008946]

Hi, we have also had this problem.

I'm not sure if this had anything to do with it, but on Friday we expanded the storage space on our host by adding a new 600gb SAS Drive.

We didn't do anything other than add the drive so it showed up extra free space. The location of the backups didnt change as they are stored on a different physical server. And we didn't make any changes to the jobs.

Since we have done that two of our backup copy jobs have been running very slowly, when looking in the job logs we can see this same message.

It appears to be running very slowly because it is trying to send the whole backup file.

Did you have any success?

Our case no. is #00685809

Many Thanks

[foggy]

Since we have done that two of our backup copy jobs have been running very slowly, when looking in the job logs we can see this same message.

Just to clarify, are you talking about backup copy jobs, not regular backup jobs, as in OP's case?

[y1008946]

Hi Foggy, yes sorry I am talking about backup copies.

If you dont think it is related I can create a new thread?

Many Thanks

[foggy]

Not sure, let's wait for what our engineers could tell after reviewing the logs.

Btw, what about the original backup jobs? Do they have any similar warnings/behavior?

[y1008946]

The engineer has left for the day now, and isn't really sure what the problem is after reviewing the logs, its going to be some time until we have any help which is why I've posted here (and they are the two most critical VMs typically!).

The original backup jobs have no problems.

It seems to be trying to send the whole file, rather than the changes since the last backup copy.

Is there any way to reset it to get it back to sending the changes rather than the whole file?

Thanks very much

[foggy]

Actually, backup copy job always sends changes, unless its previous run was not properly completed for some reason.

[y1008946]

Actually, I didnt notice this until looking deeper, the day after the extra disk was added, the two backup jobs had this message in the job logs:

CBT data is invalid, failing over to legacy incremental backup. No action is required, next job run should start using CBT again.
If CBT data remains invalid, follow KB1113 to perform CBT reset. Usual cause is power loss.

[foggy]

At least now we know what could confuse the backup copy job. Seems the reason is CBT failure on the original job and this is what actually should be investigated.

[y1008946]

Ok thanks.

Is there anything we can do to fix the backup copy jobs?

[Vitaliy S.]

Backup copy job has to finish calculation of digest data of the VMs and then will transfer the new blocks.

[y1008946]

I somehow managed to get the backup copy job to resync and it send hard disk 1 very quickly.

The steps I took was to backup the VM again and change from WAN Accelerated --> direct --> WAN Accelerated.

It said that it was 'Creating fingerprints for Hard disk 1', once it did that it ran very quickly (the usual speed) and it completed 20% of the job (hard disk 1) before it started going slow again at hard disk 2

Is there a way I can do this for hard disk 2?

I don’t really know how I managed to do it for hard disk 1, it seemed to be luck.

Thanks

[Vitaliy S.]

Not sure I fully understand what you're trying to do with disk 2. Changing transfer mode should not affect digest calculations for virtual disks. Most likely digest calculations has completed and then changed data has only been transferred.

[mlinders]

We had to reset CBT on the VM in practice because there were some non-default settings in the VMX. Presumably left overs from the "Veeam eats your data" method we used earlier. The problem started a few days before we did that, so I'm sure it's not the cause of the "disk path has been changed since last transfer" error.

Because we had a factor 3 increase in back-up times since changing to forever incremental from reversed incremental, I had to change back to the reversed incremental before being able to wait for the CBT reset results. Because of this change we don't know if the CBT reset, or the changing back to Reversed Incremental fixed our problem. But the change in back-up method is more plausible.

[foggy]

Thanks for getting back with the results of your case, much appreciated.