Verification of clone - failure
A partition and disk imaging/cloning program
Brought to you by:
steven_shiau
Menu
▾
▴
#149 Verification of clone - failure
open-works-for-me
5
2025-05-11
2012-05-24
No
Problem with the following is that I am not sure that it is a Clonezilla 1.2.12-37 issue or mine. My best guess is that it is yours, so here goes. Something on your CD does not like 1tb hard drives, maybe!
I am encountering PartClone image failure messages almost 100% of the time when no protection (fsck) is applied. Each is reproducible, consistently. I power down my box normally and insert the Clonezilla 1.2.12-37 disk and boot up. I begin a partition backup from my 40gb Intel SSD to either of my 1tb WD hard drives at any stage of filling. The image is prepared and saved. The verification fails with (from the /var/log/partclone.log):
"
Partclone v0.2.45 http://partclone.org
Starting to check image (-)
Calculating bitmap... Please wait... done!
File system: EXTFS
Device size: 15.7 GB
Space in use: 6.2 GB
Free Space: 9.5 GB
Block size: 4096 Byte
Used block : 1518420
CRC error again at 0...
"
This error is consistent across all failures. This is 100% reproducible.
I have learned through lots of trial, errors and practice that fsck on the destination 1tb WD EXT4 hard drive 'helps'. I use fsck on my storage devces regularly during the week but this still helps. My routine is to boot Clonezilla to the command prompt and "sudo fsck -f /dev/sdb1" on the destination drive, reboot and backup. I have not started a Clonezilla backup in recent memory without a fsck cleaning. This works 90% of the time.
About 10% of the time the first cycle of fsck doesn't work so I have to cleanse the 1tb WD EXT4 hard drive a second time. I have never had a failure after a second cleaning.
100% of the time I backup a partition to a 110gb ADATA SSD and the image verification is good, each and every time.
I use one 1tb WD EXT4 hard drive at a time to save my work. With daily and hourly incremental backups a drive lasts me a little over a month. With all the activity I can see why fsck may help. I cannot use fsck in a script - too much interactivity. When a drive reaches 90% filled, I go to the other 1tb WD EXT4 hard drive. I use gparted to format the drive to reiserfs. This removes all(?) traces of EXT4. I then reformat the drive as EXT4 and move all my backup scripts over to the new drive. I save a Clonezilla OS partition backup to 3 separate drives at least twice a week.
The 110gb SSD has never had a failure. My earlier reiserfs on the 1tb WD EXT4 hard drives was also hit by this. PartImage and fsarchiver on the SystemRescueCD had no problems. The reason I primarily use your CD is the verificiation. Of my successfully saved Clonezilla backups, not one has failed to restore. Thank You.
This problem has existed with all my versions of Clonezilla. It may be a verification failure bug. I am about to invest in two 3gb hard drives and I need some input as to whether my problems are a result of large drives, ergo the bug report. Short of a low level format (do they do that anymore?) I do not know what else I can do to diagnose the issue.
Sorry for the rambling. Any input is appreciated.
Thank You
Please give Clonezilla live 1.2.12-48 a try. It comes with partclone 0.2.48 and the problem might have been fixed.
Steven.
Thank You for the quick reply.
Got a problem. I do not understand your versions. I looked for -48 and I couldn't find it. I did find -52(?) in testing but I am not willing to load testing software for my production machine.
I did find 'oneiric' which is marked the latest but I am not sure.
Would you please give me the name and location of what you consider the 'latest stable release' and I will be glad to try it. The version that I am using now, -37 is said on your site to be the latest stable. It will be a few days before I do a full cloning then I will get back to you.
Hope this helps.
Thank You.
It was a typo. Sorry.
It should be Clonezilla live 1.2.12-58:
https://sourceforge.net/projects/clonezilla/files/clonezilla_live_testing/OldFiles/1.2.12-58/
Today we have another testing released:
https://sourceforge.net/projects/clonezilla/files/clonezilla_live_testing/1.2.12-60/
It will be the next stable release if nothing weird happens...
Steven.
I downloaded version -58 and completed a routine backup.
A 1tb hard drive which is not active but contains about 93% data passed on the first try.
The current 1tb hard drive which I use on an hourly basis for incremental backups failed the image check with the same log on three "fsck -f /deb/sdb1" tries but then passed on the fourth attempt.
A 110gb SSD passed on the first try as usual.
Did you also do a memtest check, too?
Maybe the problem is on the hardware...
Steven.
I downloaded -60 and everything is the same - still buggy!
Do memtest sometimes but did it again - no errors
Am backed into a corner - workaround must be used - I saved to 120 SSD and copied the good clone to each of the 1tb hard drives - this gives me three backup copies but they are not independently saved
to recap - I used partimage and fsarchiver on these two 1tb hard drives when they were reiserfs - when I changed to EXT4, I used fsarchiver - no problems - I would continue using fsarchiver but no way of checking copy
Sent an email to partclone maintainer about using with 1tb hard drives but I never received a reply - I was specifically interested in the 'nochecksum' option - it may be entirely possible that the clone is good and the checksum failed - if I can clone a copy without a checksum check then I can test the result for accuracy - it may just work!
Hope this helps
I wonder about your Cmd line check, you have done it to sdb1.
Are you sure it is sdb1, you can check that by applying a lable, or using a UUID instead this is directly coupled with your specific devic, while sdx is dependant on your (total) PC hardware?
A question: you did read /var/log in Terminal. Do you know how to read and save (print) the totaly screen scrolling during Clz execution, especially if in error!
Thanks for the help
All my outside and inside storage devices are labelled and I can see lights flashing to confirm the matching label and device.
I am lost on your last comment what is "during Clz execution" ?
Sorry to bother you so soon
I just completed the changeover from one 90% used 1tb hard drive to one newly formatted EXT4 1tb hard drive and I completed a clone job as the first item on the drive.
100% success - first time - no fsck - no checksum failure
Good Day . . .
I tried another cloning and I receive the usual checksum error.
This bug report is going no place and too much time has been expended so I am reverting back to fsarchiver.
Keep up the good work and close this bug report.
Although, keep it in mind should anything like this happen again.
Thank You
Somehow you are the only one reporting this... and it seems we can not reproduce the problem here...
Feel free to reopen this bug if you have something new.
Therefore I am closing this bug.
Steven.
Ran into the same thing - a killer. Something hit windows server 2008. I don't trust MS for backup and went over to the friend to help - used clonezilla for an independent backup before doing more work in the machine. Every time clonezilla (default settings) would complain about a CRC error on the image. I know there are bad spots on the original, thought I misread the message. Previously ran multiple chkdsks /r on the source partition. No errors on any data, etc. - clean, in other words, for a save. This is 600GB and it takes 1/2 day to try anything. Backup on USB drive. /var/log/partclone.log said the same thing on 3 backups. I took the backup drive, that never had any complaints, in win7 slow format, previously had run chkdsk /r on it, ran chkdsk /r again, of course zero complaints, just a whale of more time gone.
After the 3rd backup and same complaint, CRC error in image, I took the backup drive over to win7 loaded more files to see if clonezilla deleted the file it called bad (and I would find the truly bad spot by writing something on it and then trying to read it). Read everything on that drive, including what clonezilla put there, with zero problems. 2 days later after all this, I looked around and saw this message, someone else with NO problems on the backup drive yet clonezilla/partclone complained repeatedly about CRC error.
You know what it is like when every attempt takes 1/2 day. 2 days later, using another product to back up the partition. Another 1/2 day for it, not yet done. Then maybe get back to actually trying to fix the problem? Not nice. I don't need bogus errors. So, do I have a real clonezilla backup or do I just always take my chances with clonezilla? At 1/2 day per try, I can't go on and try other options besides partclone, etc.
Anyway, it is still a nasty problem. This partition has about 240GB of data/programs. Of course, I can only try 1 thing at a time. Very slow, as many recoveries are. (Clonezilla images come to about 87GB, but maybe that is real since there seem to be tons of log files - MS SQL junk.)
This kind of issue normally is on hardware, either RAM, network cable, or something similar.
This is very difficult to debug and see why. Therefore I suggest you try different hardware to see if it's always reproducible.
Steven.
I know this is an old thread but it saves creating a new issue.... I use a Clonezilla Live boot-able DVD. From past experience I always do a verify image for every SaveDisk, so that I know what I have backed up is going to work should I need to restore.
My backups are sourced from a laptop internal 256GB SSD containing 10 partitions, split between Win10 NTFS, a couple of Ubuntu Ext4 and a NTFS data partition, plus the usual small partitions to support Windows and efi\grub booting etc... totaling around 160GB or so. Backups are made to an external USB3 2GB NTFS hard drive. CloneZilla Live is run off DVD via a laptop internal DVD drive.
For backing up I use the SaveDisk option as a non expert user, and I use the old parallel compression method, no encryption, check of image followed by shutdown.
99% of my backup jobs complete successfully. Rarely I get a image check fail, but they do sometimes occur - if they do I check my NTFS drives using Win10 and then repeat cloning which usually succeeds on the next attempt.
Recently (back in v3.1 or so) you introduced a new compression option zstdmt - I have never had SaveDisk complete successfully using this compression option. Usually one of the partition images fails the check process. I tried v3.2.0-5 today using zstdmt and the SaveDisk failed right at the end of the final partition.... most annoying!
When I next try I will take some photos on my phone to show the fault. Is there some way of getting CloneZilla Live to save an event log somewhere so I can provide technical detail for this problem? (It would be nice if there was a Clonezilla GUI menu option for writing logs to another drive for debugging purposes).
My h/w Dell M6700 laptop, Intel i7-3840, 24GB RAM. 256GB SSD, Int DVD drive plus Ext USB3.0 Samsung drives.
Last edit: redbaron192 2025-02-21
I would suggest you do a memtest first to make sure your RAM is flawless.
We never have such an issue here, and occasionally when someone reports this issue, normally it's a hardware issue, like RAM, network cable, CPU fan...
" (It would be nice if there was a Clonezilla GUI menu option for writing logs to another drive for debugging purposes)." -> In Clonezilla live >= 3.2.1-7, in the beginner mode, the option "-plu" was introduced which if you enable it will copy the log files to your Clonezilla live USB drive.
Steven
Hi Steven,
Been doing some more testing of my verification issues (previous comment 2025-02-21)...
For faster backups I switched to using a new internal NTFS SSD instead of the external NTFS USB drive (This took USB out of the equation as well). It doubled my backup speed but still got occasional CRC verification failures.
I know from experience that writing NTFS from Linux can cause NTFS FS corruption so I decided to make my Clonezilla target EXT4 instead of NTFS (to rule out any NTFS FS issues).
So far (3 out of 3), I have not had any CRC failures - This may be indicating that the underlying problem is the Linux NTFS driver causing of these intermittent CRC failure and not Clonezilla itself.
I'll use EXT4 as the Clonezilla target FS from now on so I should be able to give a more definitive answer regarding nailing down this CRC issue in the future.
BUT... Now I have now found another issue which prevented me from copying my backups off the EXT4 SSD. When Clonezilla saved the ".zst" files, the permissions were set to 600 (and not 644). This happened 3 out of 3 times. See attached screenshot.
I was using a bootable Clonezilla USB stick, clonezilla-live-3.2.1.9-amd64.
No errors listed in the clonezilla.log file.
(After doing "chmod 644 .zst" and for the parent folders "chown username " and "chgrp username *" I could move the Clonezilla backups to an external USB drive).
Last edit: redbaron192 2025-04-20
Yes, those files might contain some sensitive data. Hence after saving, their modes are changed to 600.
With root privilege, you can read it absolutely.
Steven
Hiya, I got a failure this morning doing a backup with my new setup. I immediately repeated the backup process and the second time it verified successfully. I have the all log files for both attached. The files from the first failed attempt (backup named 2025-04-29-08-imgWin10good) are all before time 09:11:00. All files after 09:11:00 are from the second successful attempt (backup named 2025-04-29-08-imgWin10again). Both backups used identical source & target drives.
I just did a comparison of both sets of logs using "Meld" and they appear to be identical barring the times and backup names. I can't see any cause of failure logged.
" the second time it verified successfully. " -> So sometimes it works, sometimes it does not.
Normally this issue is related to hardware.
I suggest you do a memory test, and check the CPU fan and CPU temperature, etc.