Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
Have done my best to check that my question is not already answered: how do
you validate the image of a partition?
When I generate an image of a given partition on a local hard drive, and save
the image to some location, say another hard drive, ftp, or whatever, the
process consists in compressing and transferring a large amount of data.
During this process part of the image, during storing, or transfer could be
A related question, as a newbie to G4L, is how to get an MD5 checksum
generated during the imaging process of a partition?
So say I have an MD5 checksum of the image, it can be useful if I want to copy
the image to another location. I can then check to see if the copy is valid.
But how can I check if the original image generated is not corrupt? Even if I
generate a MD5 checksum of the orignial partition, it won't be the same as
that of the image, as the partition is not compressed and the image is?
One way I thought of is to restore the image to another hard disk and then
generate an MD5 checksum of original partition content, and one of the
restored partition. This will likely work, but requires quite a bit of free
space, and, is quite time consuming.
Is there a better way? Is there some way to ask G4L to go back and look at the
source partition and validate the image generated?
The whole point of making an image of a partition is to protect against
disaster. Restoring an image and booting from it is not a thorough way to make
sure everything is ok. Once disaster strikes, it's too late. Like most people,
having had hard disks and USB memory sticks fail in the past, image validation
Thanks for any help.
Michael Setzer II
This has been asked before, and generally, the best answer is that the
compression programs all have test options.
lzop -t image.lzo
Similar options for the other compression methods.
I once had a problem with a brand new server that would result in corrupt
images as the ftp server.
Images would fail on restore, and the lzop -t would result in error.
Did the same image to another older server, and it passed with no issues, and
past lzop -t.
Ran a full memtest on the new server, and when thru first 7 test with no
issues, but then test 8. Was showing the exact same difference betwen the good
image and bad? Turned out one of the memory sticks was failing under the load.
Removed the bad one, and it worked fine. Vendor then replaced both sticks with
a new pair, and it has worked for for almost 10 years now.
I'd have to double check, but I believe this is documentation. Especially, the
first time you use it to run the test.
With a local usb hard disk, it would be easy to run the test after creation,
but when doing an image to an ftp server one would have to ssh or some other
connection to run the compression test. But usually, if it is an ftp error
that shows up already. That is also why it is good to use the time option to
check that the presentages go up to 100% and don't jump due to an error. Once
had an user that had ftp server using fat32 and when it got to 2G it stopped.
Hope that answers the question.