Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

image validation

Help
xian555
2012-07-09
2012-09-10
  • xian555
    xian555
    2012-07-09

    Hello,

    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
    affected.

    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
    is fundamental.

    Thanks for any help.

     
  • 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.