Did not track enough (volume resize?)

[kslen]

Greetings.

I’m experiencing an issue with CBT after resizing the OS partition of a Windows 7 client with NTFS filesystem running UrBackup version 2.1.16 which is backing up to a server running Debian Jessie with ZFS as filesystem and UrBackup version 2.1.19. Currently not experiencing other issues on either side and all of my other clients are completing backups successfully. Both client and server is up to date and I’ve tried rebooting them multiple times with no change.

I’ve attempted deleting existing shadow copies on the client, but this had no effect.

Here’s the log from the client:
Starting scheduled incremental file backup…
Did not track enough (volume resize?). Tracked 45056 should track 47264. CBT will disable itself once this area is written to and then a system restart will be needed to enable it again.
Getting changed block data from shadow copy \?\GLOBALROOT\Device\HarddiskVolumeShadowCopy19 failed: More data is available. (code: 234)
Scanning for changed hard links on volume of “c:”…
Indexing of “Pictures” done. 1 filesystem lookups 0 db lookups and 0 db updates
CLIENT: Loading file list…
CLIENT: Calculating file tree differences…
CLIENT: Calculating tree difference size…
CLIENT: Linking unchanged and loading new files…
Waiting for file transfers…
Waiting for file hashing and copying threads…
Saving file metadata…
Writing new file list…
All metadata was present
Transferred 6.46909 MB - Average speed: 139.112 KBit/s
(Before compression: 22.3439 MB ratio: 3.45395)
Time taken for backing up client CLIENT: 15m 12s
Backup completed with issues

Since this is likely a client issue, I will only post server logs if needed.

I’ve tried searching for a valid solution, but not found anything yet. Hope I’m not wasting anyones time.

In advance; thank you for your attention.

[TomTomGo]

Have you tried to reset CBT ?

cd C:\Program files\UrBackup
urbctclt reset x:

Force a full image volume backup with ZFS backend

Yeah, cbt reset with cd C:\Program files\UrBackup urbctclt reset x: may help. Can you also investigate if only MFT!=MFTMirr is the problem? Use losetup --offset=$((512*1024)) to setup the volume. Then use ntfsfix to fix the NTFS error. If this is something the naturally occurs, there is already code in UrBackup to fix it…

[uroni]

Hmm, I rather thought it would work after a reboot. If not uninstalling, rebooting and then installing it again should work. I’ll look (again) after making it fix itself with simply rebooting.

[kslen]

Well, this is awkward. Turns out it mostly comes down to user error.

As the UrBackup installer has more or less consistently cleaned up previous issues for me, I accidentally managed to install the regular client without CBT after uninstalling the CBT version. /facepalm

I reinstalled the correct version with CBT, but still got the same error. I then executed “cbtctctl.exe reset C:” as suggested by TomTomGo and rebooted the machine with no progress: More data is available. (code: 234)

While muttering something about VSS to myself…
vssadmin delete shadows /For=C: /All
cbtctctl.exe uninstall C:
shutdown /r /t 0

cbtctctl.exe install C: n-c
Driver installed successfully
Unlocking bitmap file failed. Err: 1
Cannot create bitmap file. Err: 32
Unable to install bitmap file

I then found a comment where you pointed out that this usually means the machine is waiting for another reboot. Does this mean that the driver is already installed and the output is incorrect in this regard?

Unless this second reboot is required - given that I didn’t uninstall the driver when I deleted the shadow copies, then the only thing I can spot that is different from a simple uninstall, reboot, install, reboot is the deletion of the shadow copies following the installation of the client with CBT.

shutdown /r /t 0
urbctctl.exe status C:
CBT status of C:: Enabled. Tracking active.
Crash consistency: Disabled
Version: 2.5

Should crash consistency be enabled?

urbctctl.exe status D:
Change block tracking disabled on D:

Which is fine, as the files I’m backing up is located on C:.

Starting unscheduled full file backup…
Change block tracking active on volume c:
Indexing of “Pictures” done. 1 filesystem lookups 0 db lookups and 0 db updates
CLIENT: Loading file list…
CLIENT: Started loading files…
Waiting for file transfers…
Waiting for file hashing and copying threads…
Saving file metadata…
Writing new file list…
All metadata was present
Transferred 1.11569 GB - Average speed: 1.83952 MBit/s
(Before compression: 6.53536 GB ratio: 5.85766)
Time taken for backing up client CLIENT: 1h 40m 14s
Backup succeeded

Is there a resource where I can read more about the parameters of urctctl.exe? I’ve looked for it in the usual places, but found no reference outside of forum threads. And I can’t seem to tickle the executables parameter in any way that makes it reveal its secrets.

Thanks again for your time.