Clonezilla verify image fails

Question

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?

Answer 1

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.

Answer 2

This question and answer are pretty old, so I won't ask for more information.

You state:

I have a HP Pavillion dv4 laptop that is in the process of eating its (second) hard drive

This makes me suspect the hard drive in question is physically damaged. Because of that, any data you collect from it is going to be suspect as well.

You also mention that:

when it goes back through and tries to verify the image, it gets a CRC read error every time on sda1

When a disk image program runs, it creates an exact copy of the data read from the disk. The verification process, where it reads the data from the disk again(?) seems as though it fails consistently. There are a few possible reasons, but one reason is that reading that section of the source (original, failing) disk produces different data each time. That explanation is consistent with the first statement that you don't trust it.

In that case, I recommend the following:

Assuming you have the spare disk space (always a question), you have some options:

• Fast and dirty: Take the most recent image (that failed the CRC), and run a disk repair tool on it. This will probably get you a good fraction of the original data, and there's a decent chance this includes all the data you care about. The challenge is that you're making automatic changes to your only copy of the data on trustworthy media.
• Prudent: Make a copy of the most recent image (that failed the CRC) and run a disk repair tool on the copy. This gets you all the benefits of the above, but you can then fall back to cautious and slow (below) if you're not completely satisfied.
• Cautious and slow: Use a tool like ddrescue to carefully read the failing disk and try to recover as much data as possible to a new location on the disk, possibly using the existing image to help inform ddrescue.