On Fri, 31 Dec 2004 13:50:21 -0700, Ted Hilts
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