Volumes with active change block tracking and no crash persistence (v2.13):
C:
Volumes without change block tracking:
G:, D:
the backup itself reads the entire disk, and there is no mention of CBT in the log:
|12/24/18 02:14 |INFO |Starting scheduled incremental image backup of volume "C:"...|
|12/24/18 02:14 |DEBUG |Backing up SYSVOL...|
|12/24/18 02:14 |DEBUG |Backing up SYSVOL done.|
|12/24/18 02:14 |DEBUG |Backing up EFI System Partition...|
|12/24/18 02:14 |DEBUG |Backing up EFI System Partition done.|
|12/24/18 02:14 |INFO |Basing image backup on last incremental or full image backup|
2019-01-21 18:33:09: Change block tracking active on volume C:
2019-01-21 18:34:03: ERROR: Need previous client bitmap for image backup with CBT. Disabling CBT.
Some clients from outside the network connect through SSH tunnel, so their IP address is registered as 127.0.0.1. However, this hasn’t been a problem till after upgrading the server and/or the client to the versions mentioned above (I updated them both the same day, so it’s hard to tell which is responsible).
The idea is that the Server does not send the bitmap if it doesn’t think it is a CBT client. If the clients run on the same IP it might get them confused. You can probably also look at the version on the server status page (can be enabled as column), to see if it shows -cbt there or not.
Ok, so I just saw this on one of my clients and turns out there is a) a bug in 2.3.x where the bitmap is not requested from the server and b) the server does not intialize memory and so it randomly sends the bitmap or not. Ouch. Will be fixed with the next 2.3.x cbt client (2.3.6).