I saved my entire disk to a networked xp drive. Everything seemed to go correctly for saving the image. I compressed using lzop. Now I am trying to restore and I get compressed data violation and it stops the restore. Anything I can do to recover. From reading in the forum it seems I should stay away from lzop, is that correct?
rkshack
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OOps... Something went wrong with the "monitor this forum" function in my sf account. I did not get any notification about this. Sorry for the late response.
Great, thanks to lzop I have my whole disk all fucked up. All data lost. Absolutely wonderfull.
lzop <stdin>: compressed data violation
And this happened for both of my two partitions (ntfs and ext3)! Why the hell are you recommending lzop compression in clonezilla when it's causing so much trouble (I have found several reports on this forum)?! This compression should be banned! I have LAN, no network problems, and clonezilla wasn't able to save disk image and restore it the next day! I wish I had used gzip, damn it! I really don't understand why it shouldn't save the image correctly on LAN. Does it use UDP instead of TCP or what? Or is it just messy compression? Obviously it is. Damn it, damn it, damn it. Just give there a warning, ffs! Just a single sentence "some people reported problems" and I would never have used it!
If you have *any* idea how to get data from corrupted lzop file split into three parts, suggestions are really welcome.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just discovered this same problem on one of my backups.
lzop: <stdin>: Compressed data violation
This was on a dual Opteron cpu , none of my other computers had this
problem so it may be a speed related.
I think I will start testing my backups to make sure they will uncompress.
Besides this little glitch Clonezilla is working great.
I have successfully backed and restored windows 2k, xp and Red Hat software
on several hardware configuations over the network.
I will try switching the compression and see if that fixes my problems.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, the only thing I can say is sorry.
We did not reproduce such problem here. I think more than 10k downloads, and most of them, maybe 99% more, does not have such a problem. Looks like the only problem with lzop is in the network quality. That's why we still set lzop as the default option, since it's faster and the size is only slighter larger than that of gzip.
About a week ago, I was discussing with Mark Binner (http://clonezilla.sourceforge.net/testimonial/) that we might set the default value to be -z1 instead of -z3 in the future.
Anyway, actually the image files are just partimage + lzop + split, so I would suggest:
1. backup all the image files you have. This is very important before you "play" those images.
2. run command like this:
( for img in /home/partimag/$IMAGENAME/hda.*; do
cat $img
done
) | lzop -dc > hda-img
Replace the $IMAGENAME/hda with your image name. You can save the above command as a script to run it.
then this hda-img is the image file with partimage format, without compression. Maybe then you can try to use partimage to load it and give it a try to restore it to the partition.
Good luck.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I already tried that procedure. lzop is not able to decompress that image (compressed data violation). there's no option to skip errors (it may not be even possible). this holds for both my hda1 and hda2 image. What I really don't understand, how data can get corrupted even on less quality network (I have standard home 100mbit). We have TCP, we have checksums. For many years I haven't had a single corrupted file transfered over my network. It must be some algorithm problem.
What I am sure of is that I will not use lzop ever again. And I am not sure of Clonezilla, sorry for saying that. I value my data more than to save 10 minutes by "better" compression method. That was really not worth it. And for future users, you should really consider to add a warning/info there, that lzop can mailfunction on (say) "less quality networks".
You know, you are wrong in one way. In company environment, where they backup/restore dozens of images a day and there are skilled people paid for their job, they can easily try various settings and choose what's best for them. There's no need to "recommend", they will probably try all options, because they will repeat it hundrends of times after that. In home environment, people just need to have their data safe. The default option must work flawlessly. They have no experience and they trust you that you recommend what's best for them. A few saved seconds doesn't matter, for they backup *once*! If you recommend them not-always-working-but-a-little-faster algorithm, well, that's a really great advice.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, that's true. Thanks for your advice. Actually it's until recently, such problems were reported, and some of them were identified as not related with lzop, while some of them are.
Last week when I discussed with Mark Binner, actually I already decided to switch to option -z1 in the future version.
The problem here is, we can not always reproduce this bug, so that's not easy to debug and fix it. The best solution is to avoid that, and you are right.
Thanks for you advice.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I saved my entire disk to a networked xp drive. Everything seemed to go correctly for saving the image. I compressed using lzop. Now I am trying to restore and I get compressed data violation and it stops the restore. Anything I can do to recover. From reading in the forum it seems I should stay away from lzop, is that correct?
rkshack
OOps... Something went wrong with the "monitor this forum" function in my sf account. I did not get any notification about this. Sorry for the late response.
About your question,
Not really. If the network quality is good, and you are putting the image in the network-based dir, it's ok. lzop is much faster when saving. For more info, check this:
http://drbl.sourceforge.net/faq/index.php#path=./2_System&entry=38_error_when_saving_ext2_3.faq
Great, thanks to lzop I have my whole disk all fucked up. All data lost. Absolutely wonderfull.
lzop <stdin>: compressed data violation
And this happened for both of my two partitions (ntfs and ext3)! Why the hell are you recommending lzop compression in clonezilla when it's causing so much trouble (I have found several reports on this forum)?! This compression should be banned! I have LAN, no network problems, and clonezilla wasn't able to save disk image and restore it the next day! I wish I had used gzip, damn it! I really don't understand why it shouldn't save the image correctly on LAN. Does it use UDP instead of TCP or what? Or is it just messy compression? Obviously it is. Damn it, damn it, damn it. Just give there a warning, ffs! Just a single sentence "some people reported problems" and I would never have used it!
If you have *any* idea how to get data from corrupted lzop file split into three parts, suggestions are really welcome.
I just discovered this same problem on one of my backups.
lzop: <stdin>: Compressed data violation
This was on a dual Opteron cpu , none of my other computers had this
problem so it may be a speed related.
I think I will start testing my backups to make sure they will uncompress.
Besides this little glitch Clonezilla is working great.
I have successfully backed and restored windows 2k, xp and Red Hat software
on several hardware configuations over the network.
I will try switching the compression and see if that fixes my problems.
Well, the only thing I can say is sorry.
We did not reproduce such problem here. I think more than 10k downloads, and most of them, maybe 99% more, does not have such a problem. Looks like the only problem with lzop is in the network quality. That's why we still set lzop as the default option, since it's faster and the size is only slighter larger than that of gzip.
About a week ago, I was discussing with Mark Binner (http://clonezilla.sourceforge.net/testimonial/) that we might set the default value to be -z1 instead of -z3 in the future.
Anyway, actually the image files are just partimage + lzop + split, so I would suggest:
1. backup all the image files you have. This is very important before you "play" those images.
2. run command like this:
( for img in /home/partimag/$IMAGENAME/hda.*; do
cat $img
done
) | lzop -dc > hda-img
Replace the $IMAGENAME/hda with your image name. You can save the above command as a script to run it.
then this hda-img is the image file with partimage format, without compression. Maybe then you can try to use partimage to load it and give it a try to restore it to the partition.
Good luck.
I already tried that procedure. lzop is not able to decompress that image (compressed data violation). there's no option to skip errors (it may not be even possible). this holds for both my hda1 and hda2 image. What I really don't understand, how data can get corrupted even on less quality network (I have standard home 100mbit). We have TCP, we have checksums. For many years I haven't had a single corrupted file transfered over my network. It must be some algorithm problem.
What I am sure of is that I will not use lzop ever again. And I am not sure of Clonezilla, sorry for saying that. I value my data more than to save 10 minutes by "better" compression method. That was really not worth it. And for future users, you should really consider to add a warning/info there, that lzop can mailfunction on (say) "less quality networks".
You know, you are wrong in one way. In company environment, where they backup/restore dozens of images a day and there are skilled people paid for their job, they can easily try various settings and choose what's best for them. There's no need to "recommend", they will probably try all options, because they will repeat it hundrends of times after that. In home environment, people just need to have their data safe. The default option must work flawlessly. They have no experience and they trust you that you recommend what's best for them. A few saved seconds doesn't matter, for they backup *once*! If you recommend them not-always-working-but-a-little-faster algorithm, well, that's a really great advice.
Yes, that's true. Thanks for your advice. Actually it's until recently, such problems were reported, and some of them were identified as not related with lzop, while some of them are.
Last week when I discussed with Mark Binner, actually I already decided to switch to option -z1 in the future version.
The problem here is, we can not always reproduce this bug, so that's not easy to debug and fix it. The best solution is to avoid that, and you are right.
Thanks for you advice.
Please keep us posted.
Thanks.