You are not logged in.
We have OneDiff operating on a host copying 4 VMs. One VM that we have had for many years has 6 disks:
2019-01-17T08:28:57| scsi0:0.fileName = "fs-51.vmdk"
2019-01-17T08:28:57| scsi0:1.fileName = "fs-51_1.vmdk"
2019-01-17T08:28:57| scsi0:2.fileName = "fs-51_2.vmdk"
2019-01-17T08:28:57| scsi0:3.fileName = "fs-51_3.vmdk"
2019-01-17T08:28:57| scsi0:4.fileName = "/vmfs/volumes/adf216ff-b089449d/fs-51/fs-51_4.vmdk"
2019-01-17T08:28:57| scsi0:5.fileName = "fs-51_4.vmdk"
The initial backups perform successfully and there are no glaring errors or messages. All VMs (except one) produces a _XSIBAK file. That problem VM always start the second OneDiff backup as if it's the first time OneDiff has seen it and takes hours (just like the first backup).
First Disk:
2019-01-17T08:39:32| [OESfs-51] Disk copied to /vmfs/volumes/XXXXX/OESfs-51/fs-51.vmdk
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/datastore1/fs-51/fs-51_1.vmdk'...
Second Disk:
2019-01-17T09:33:34| [OESfs-51] Disk copied to /vmfs/volumes/XXXXX/OESfs-51/fs-51_1.vmdk
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/datastore1/fs-51/fs-51_2.vmdk'...
Third Disk:
2019-01-17T10:07:33| [OESfs-51] Disk copied to /vmfs/volumes/XXXXX/OESfs-51/fs-51_2.vmdk
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/datastore1/fs-51/fs-51_3.vmdk'...
Fourth Disk:
2019-01-17T10:08:11| [OESfs-51] Disk copied to /vmfs/volumes/XXXXXOESfs-51/fs-51_3.vmdk
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/adf216ff-b089449d/fs-51/fs-51_4.vmdk'...
Fifth Disk:
2019-01-17T12:46:55| [OESfs-51] Disk copied to /vmfs/volumes/XXXXX/OESfs-51/fs-51_4.vmdk
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/datastore1/fs-51/fs-51_4.vmdk'...
Final Message:
2019-01-17T12:47:05| [OESfs-51] Disk copied to /vmfs/volumes/XXXXX/OESfs-51/fs-51_4.vmdk
2019-01-17T12:47:09| [OESfs-51] info: Updating CID at [/vmfs/volumes/XXXXX/OESfs-51/fs-51.vmdk]
2019-01-17T12:47:09| [OESfs-51] info: finished OneDiff backup, CID updated
2019-01-17T12:47:09| [OESfs-51] info: backup complete
2019-01-17T12:47:09| [OESfs-51] info: finished doing a first copy in a diff scope, subsequent backups will be differential
2019-01-17T12:47:09| [OESfs-51] info: should you need to use the mirror VM, register it manually at the backup ESXi host
Any troubleshooting ideas?
Offline
If, for some reason, the quick Trivial Check or a full checksum check of the subsequent backups after the first one fail, OneDiff will reset the chain to perform a full backup, in order to start with a valid seed. So the log that we need to assess you is the second run in the OneDiff cycle.
Just one changed bit in a hash check will end up in a different checksum. Most of the times checksum check failures are due to some read, or write error in some part of your virtual disk, which in turn corresponds to some physical sector in the underlying physical media.
This does not mean that the resulting VM is unusable, in fact, most of the times you can switch it on and use it. An XSIBackup full checksum check is unfeasible if the disks are a bit worned out.
Offline
ok. thanks.
Offline