Since upgrading some clients to CBT mode, i have those type of messages in server’s log file when UrBackup cleans up :
20/06/16 13:02 INFO Deleting incomplete image file "/media/backup/urbackup_btrfs/SV401/160618-2030_Image_SYSVOL/Image_SYSVOL_160618-2030.raw"...I’ve never observed them before using CBT mode.
What should be the reason ?
Regards,
It is improbable that this has something to do with the CBT. Does the client have a “system reserved” volume?
Yes it have … Now it seems to be ok with the last backups.
However i’ve got another issue with the full image restoration.
I’ve tested to restore a full client image on a clean VM with exactly the same virtual hardware : HDD, CPU, RAM, NETWORK, …
Restore process is OK but when the client reboot, it goes in the WIndows repair mode systematically and VM is unable to boot properly.
OS : Windows 2008 R2 with a 100MB system reserved volume
Backup directory looks fine :
/media/backup/urbackup/SV54/160621-1822_Image_C:
total 45G
-rwxr-x--- 1 urbackup urbackup 80G juin 21 18:56 Image_C_160621-1822.raw
-rwxr-x--- 1 urbackup urbackup 2,5M juin 21 18:56 Image_C_160621-1822.raw.bitmap
-rwxr-x--- 1 urbackup urbackup 2,5M juin 21 18:23 Image_C_160621-1822.raw.cbitmap
-rwxr-x--- 1 urbackup urbackup 5,0M juin 21 18:56 Image_C_160621-1822.raw.hash
-rwxr-x--- 1 urbackup urbackup 556 juin 21 18:22 Image_C_160621-1822.raw.mbr
/media/backup/urbackup/SV54/160621-1822_Image_SYSVOL:
total 25M
-rwxr-x--- 1 urbackup urbackup 101M juin 21 18:22 Image_SYSVOL_160621-1822.raw
-rwxr-x--- 1 urbackup urbackup 3,2K juin 21 18:22 Image_SYSVOL_160621-1822.raw.bitmap
-rwxr-x--- 1 urbackup urbackup 3,2K juin 21 18:22 Image_SYSVOL_160621-1822.raw.cbitmap
-rwxr-x--- 1 urbackup urbackup 6,4K juin 21 18:22 Image_SYSVOL_160621-1822.raw.hash
-rwxr-x--- 1 urbackup urbackup 577 juin 21 18:22 Image_SYSVOL_160621-1822.raw.mbr
I’ve tested with multiple backups sets with the same result, except with a backup set made before enabling the CBT mode on the client …
I’ve noticed that when backing up a full image with CBT mode enabled it transfers only 24 Mb / 100 Mb for the SYSVOL volume, is it normal ?
If it is a full image backup CBT isn’t used. CBT also isn’t used for the SYSVOL backup.
Okay i’ll made more tests because it looks very strange …
Could you tell us in which cases CBT is used ? Only incremental image backups ? File backups ? Does the CBT usage is different with a BTRFS backend storage ?
Regards,
Only for incremental image backups currently and with both image backup to VHD and btrfs raw.
You can mount the raw image on Linux quite easily to inspect the contents by the way:
LODEV=`losetup -f`
losetup $LODEV /media/backup/urbackup/SV54/160621-1822_Image_C/Image_C_160621-1822.raw --offset $((512*1024))
mount -o ro $LODEV /media/Image_C
And even with these settings ? :
When does it become effective for full image backups and / or file backups ?
To clarify i think you should give more details in the “3.Usage” section of the CbtUserManual :
Excuse me for all these questions …
Regards,
Ok, those could be incremental then. If it has the
Basing image backup on last incremental or full image backup
in the logs, they are incremental.
It already tracks the file backed up volumes, but it does not use the tracking information during backup, yet. The manual will be improved and thanks for your feedback!
Yes it has 
:
Thank you very much for your explanations / clarifications !
BTW, i’ve made another full image backup (with CBT enabled) and restore it to another test VM and it works fine, strange …
How can i check the integrity of others backups which failed after restore and rebooting the restored client ?
Regards,
I would first try to mount the restored volumes in Linux (e.g. from the restore cd), to see if something is wrong in general. Or boot from a Windows cd and run chkdsk on the restored disk.
Unfortunately there currently is no way to verify the restored partition against a image backup .hash file, only the .raw file itself. If you have logs from a failed restore I would be interested, of course.
Where can i find these logs ?
It’s at
/root/restore_mode.txt
and
/root/restore_wizard.txt
Ok thanks i’m going to make an other test and give you the logs back.
Everything looks good. If you continue with the boot repair and then click on advanced and open a command prompt. Can you access the restored disk?
Seems to be all restored correctly so far. You could further confirm this by running chkdsk d: in that command prompt.
Now the question is why it won’t boot. Are you sure it’s the same (virtual) hardware? E.g. on Xen device_model_version makes a difference.
chkdsk make some corrections but VM still not booting …
Original VM is Vmware and test VM where i restore is also Vmware, same hw version 8, same config…
Since what beta client/server version do you have the incremental image backups running (without an intermediate full backup…)?
