Linux – Clonezilla verify image fails


I have a HP Pavillion dv4 laptop that is in the process of eating its (second) hard drive due to heat issues (have since gotten it a thermal cooler pad). I purchased a 1.5TB external usb drive to back up to, with the intention of using clonezilla to write image files to the backup drive, and then duplicity (primary OS is Ubuntu) to do incremental backups.

The problem is when I boot clonezilla live from a CD, it runs thru everything, making a backup image of the various partitions (including the big 385GB Windows partition) but when it goes back through and tries to verify the image, it gets a CRC read error every time on sda1 (the Windows partition). The other partitions (Windows rescue, / and swap) all verify fine.

So… my question is this: what are my options at this point? I really don't want to lose whats on my Windows partition if I can at all avoid it. Yes, I do have HP system rescue CDs available, but that will probably involve wiping out my Linux install and restoring that from scratch as well – which kind of invalidates all the time I've spent running clonezilla on this machine thus far.

Ideas, comments, suggestions?

Best Answer

I don't know exactly why, but sometimes the HDD or SSD is in that state, that Clonezilla doesn't able to clone properly medium or verify the backupset (it happend to me wits HDD as well as SSD a few times during about 10 years). It can be on Linux EXT FS or Windows NTFS etc... It issues something like this:

syslinux.d syslinux_fs /dev/....
crc errors block_id = nnn...

For check ext2, ext3, or ext4 filesystems

Try to open Gparted (GUI), click on the wheel icon and choose repair. If it is not helped there is second way from command line is to try repair damaged blocks manually using e2fsck. For example:

ubuntu_linux:> e2fsck -f -p -v -c -c C 0 'dev/nvme0n1p2'

Switches: -f force, -p check and automtically repair all issues without prompting you for confirmation, -v verbose, -c -c inode to prevent them from being allocated to a file or directory - if this option is specified twice, then the bad block scan will be done using a non-destructive read-write test. Finally C 0 means, that you can see progress. Be patient it take a time (full NVME 500GB SSD about 2 hour+). Mostly, it helped me.

The both methods you can use repeatedly, but be avare. GParted sometimes can damage your filesystem more and unreversible as well as e2fsck, but on the other hand, in that situation, maybe the problem was only hidden, so there is no choice how to easily repair medium.

For check NTFS, FATXX etc... filesystems

Similar situation I noticed on Windows10 too (again SSD and again in the time of backup or immediately after). There is situation slightly easier. Windows immediately offer what to do - there is notification, which leads us to the page with advice, how to repair error on medium. Of course, there is again possibility to use command line chkdsk as explained in commentary above.

After healing bad block it can occur, that something will not work properly. If i t is not fundamental for OS it can be hidden for the time, when you will need to start the application, open the picture etc... If it is program or part of some installation, simply reinstall it. If sytem has any issues, try to reinstall library or simply that, where is problem.