On Wed, 27 Oct 2004 23:55:43 +0100, James Wilkinson <james@xxxxxxxxxxxxxxxxxxx> wrote: > linux r wrote (about dd): > > To make it faster, can you just do just _part_ of the directory tree > > with dd? E.g., not do a 70 g partition of / when you can maybe scrap > > your apps and just dd /home or something like that. Later you can > > remount /home over your fresh install, or mount it in /tmp and cp over > > what you need. I would think that you could get by a lot quicker that > > way. Unless of course we are talking about a production box or > > something like that. If you don't need to save log files, etc. then > > this may be a way to cut down the territory considerably. > > No. Sorry. > > dd works underneath the filesystem. All you're getting is the raw > contents of what's on disk. > > I'm going to resort to ASCII diagrams to demonstrate: you'll have > something like this on disk: > &&&***£%%%###@@@~~~~~~~~~~~???????????????............!!!!~ > where & might be blocks from /boot/initrd-2.6.5-1.358.img > ??? might be blocks from /usr/bin/emacs > * might be blocks from a picture in /home > !!! might be part of the filesystem's journal > ~~~ might be an Ogg Vorbis file that has had to be stored in several > parts. > > Get the idea? > > This is basically what you get when you copy a filesystem with dd. > When you mount a filesystem, you get the kernel's filesystem code to > sort all this out for you. When you dd, you just get the whole kit and > caboodle. Unless, of course, you deliberately only dd bits, in which > case you just get part of the whole kit and caboodle: you might get most > of /usr/, some of /home, and almost none of /tar. And quite possibly, > not enough filesystem metadata to work it out. > > (Note that on disk, Unix-like filesystems store file names separately to > the files, so given the chunk above, you wouldn't get told which file > was which). > > In any case, you'd need to know the filesystem backwards to be able to > piece together what you have. > > Sorry, > > James. > -- > E-mail address: james | Og just boggle how stupid spammer is. How stupid > @westexe.demon.co.uk | spamhaus is. How stupid spamhaven is. Og thought > | there was such thing as "evolution". How all these > | stupid people still alive? Og boggle. Boggle Og. > | -- Caveman Og > > -- > > > fedora-list mailing list > fedora-list@xxxxxxxxxx > To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list Thanks for the eplanation. Silly me, I have yet to dd a hard drive. I thought you could dd just part of a drive since I have seen /dev/whatever sometimes used in the syntax. Oh well... Geez. Too bad that a USB drive isn't more of an option. With disks as cheap as they are, it makes the most sense to do some sort of a bit-by-bit copy of the drive. You might also try something like DiskEdit. It is an old DOS based utiltiy that allows you to fix broken clusters, etc. That is, of course, unless you have a physical hardware problem with parts of that disk. I would say you have about a 50% chance that you do. I think there is an open source version of basically the same thing, although I haven't used the oss one. DiskEdit will allow you to do searches on file clusters and fix chains where the data is hosed, etc. It is in hex so it takes some getting used to. I have only used it with a FAT partition but I would be the oss similar version app would have more linux support (just a hunch - do ya think :) However , if the data is _really_super_valuable (and I presume it is for the effort here) -- another thing would be to try to get ahold of a write blocker for the drive. It is a hardware device that you plug your drive into and will allow you to plug another drive into as well. They make them for both IDE and SCSI (or both I believe). Data recovery companies have them, but I think you can buy some of them for not too much $$. You plug it and your 'target' drive in and it mounts the source drive as read only. So you are able to get a forensically (court defendible) copy of the hard drive for examination purposes. And you know, with 100% certainty, that you didn't change ONE SINGLE BIT on the source disk. If you hose the copy, you just make a new one, and you don't lose any data. Unless it *already* was lost, of course. SInce you can't normally tell what CHS (cylinder/head/sectors) may be bad on the disk, having a good working copy to play around with makes sense. Then at least you get a _data_copy_ that is independent of whatever physical problems are on that disk (new disk, new geometry). [Learned about this write blocker stuff in my computer forensics class. I haven't used it yet personally but it sounds cool.] Good luck. -- Marc Wealth is the product of man's capacity to think. Ayn Rand
