Mailinglist Archive: opensuse (3138 mails)

[Greg Freemyer <greg.freemyer@xxxxxxxxx>]

On Fri, 31 Dec 2004 13:50:21 -0700, Ted Hilts <thilts@xxxxxxxxxxxxxxxx> wrote:
>  Thanks Greg
>  

No problem, I do a lot of this kind of imaging. (My company does
computer forensics.)

>  Your first assumption applies, I want a disk image so I can plaster it back
> (somehow) onto the
>  old, a replacement or another disk (on the same system) in the event the
> current drive goes
>  corrupt on me.  On XP machines I use Acronis True Image which also produces
> a boot disk for
>  restoration purposes and will create the archive image file (a special
> compressed file taken from the disk image) which it uses for restoration.  
>  
>  YES, I can use the SuSE 9.1 first disk as a boot up and go into the menus
> and then go into "rescue" mode. Kind of obvious now you mention it but it
> did not occur to me.  Thanks very much for your
>  suggestion. I would imagine in order to do a restore I simply use the same
> boot up mechanism but
>  reverse the process again using the "dd" command with the "of=" and "if="
> files reversed.

Correct.

>  
>  However, you tweaked my curiosity on the two other considerations. 
>  
>  1.  DISK READ ERRORS
>  
>  I understand the need to use zeros for an image creation in order to
> preserve the correct number of blocks (but it did not occur to be to do so).
>  But this obviously leaves a data gap so how would one
>  be aware of those gaps in the image and how would one remedy that situation
> so that one had
>  a "complete -- without errors -- backup image or image plus some other kind
> of small backup (to cover the gap)???  

First if a read error occurs, the o/s will retry several times before it fails.

Therefore, as far as I know, if dd itself is told of a read error by
the kernel, there is nothing to be done.  The data is already lost.

The good news is that dd will tell you if it experiences an error and
it will tell you what sector(s) had the problem, so you definately
know what is going on.

I don't know how to figure out what file contains that sector, but at
least you have the rest of your data and as coherent of a filesystem
as possible.

FYI: The first thing data recovery companies do in the presence of a
malfunctioning drive is to make a dd copy of the drive, then work with
that image.

FYI2: With modern drives, if you are getting bad blocks / read
failures, it is time to replace the drive, but in our business we have
to get data off of defective drives fairly often.  This can mean
swapping electronics, or opening up the drive in a clean room.  I
don't do any of that work, so I can't give any real details.

>  
>  Again, I never thought about having a disk read error during a backup but I
> know they can happen and so I guess in doing the backup I should make
> allowance for the possibility???
>  
>  2. For FORENSIC REASONS -- md5sum
>  
>  Could I have an example?  I have never (to my knowledge) utilized md5sum,
> in point of fact I don't 
>  even know what it is and I will have to read up on it.

For instance if I am making a forensic image, I would do:

dd if=/dev/hdc conv=noerror,sync | split -a 3 -d -b 640m - backup-image.

That will create a series of 640 MB files that comprise the backup.  

backup-image.000
backup-image.001
backup-image.002
backup-image.003
.
.
.

FYI: We like to keep everything below the size of a CD.  The reasons
are historical and may no longer apply, but we still do it.  I doubt
if you would need to do this.

Then we create an md5 checksum of the 640 MB segments:

md5sum backup-image.* > md5

Then at various times during the analysis process we verify that all
the 640MB segments are still valid and have not been corrupted.

md5sum -c md5

If for some reason we need to restore the image to a drive:

cat backup-image.* > /dev/hdc

This works because all the 640 MB segments are in alphabetical order.

>  
>  Thanks again.  Your input to my problem was very helpful especially "The
> much bigger problem you have..." and "Your assumption that dd will also get
> the content of /HDD2 is wrong".  So you have
>  addressed the entire set of issues as well as my false assumption and for
> that I am grateful.
>  
>  TED

Greg
-- 
Greg Freemyer