catastrophic failure (CCTV Drive)
Jay Vaughan
EMAIL HIDDEN
Fri Nov 16 11:53:38 CET 2007
> One of the first things I tried was making a backup of the drive in
> case these recovery programs messed it up even further. However
> that was when I knew I was in trouble since no platforms were even
> able to to detect it to even mount the drive.
>
> I've tried a bunch of linux distros for data forensics and I can't
> even get the drive to detect so I can't moun it and so i have not
> been able to even back it up.
>
okay, you know the difference between the device being detected by
your system, and the device being *mounted* by your system, right?
in linux, when you hook up a drive, it will only auto-mount if your
system is configured to do so, *and* if it knows the filesystem
format of the drive by reading a few key bits of data from the drive
(which in your case are now irretrievably lost since you
'initialized' it), *and* if there is a filesystem driver that allows
the filesystem to be recognized in the context of the linux kernel.
other than that, you should still get a raw device node in /dev
somewhere that points to the physical device itself - it is from this
raw device (.e.g /dev/sda) that you can do a raw sector copy in order
to back it up. mounting has nothing to do with it: and in fact,
there is evidence that the original disk used a highly proprietary
filesystem format in the first place, so it wouldn't necessarily have
been mountable anyway. hint: there are about 30 different filesystem
types out there in la-la-land, and only a handful of them are
consumer-grade and thus 'normal' for your average PC user. there are
tons, and tons, of proprietary filesystem formats out there, too ..
mounting is the *last* stage in a device enumeration effort under
linux. there are a couple other stages before that, which you might
be misinterpreting if you're not familiar with it. as 'root
user' (either by sudo or whatever), do an fdisk -l on your system
*before* you plug the drive in, then do it again afterwards, and note
the difference. if in fact your system is recognizing the new device
as a storage device on your IDE (is it IDE? SCSI?) bus, then you
will see a new devnode added to /dev that indicates this fact. only
when this node is available will you be able to mount the filesystem
- and only *then* if there is a filesystem driver for the particular
filesystem thats physically on your disk. but you do not have this
luxury any more, since you have initialized the drive and overwritten
the filesystem entry table (or partition map, or boot block, or ..
depending on what the actual real original filesystem was all about).
you still have a chance, if your system detects the drive as a
storage device, to do a raw block copy to a locally mounted
filesystem and make a backup upon which to do a recovery effort. but
i must stress: do not do this if you do not know the difference
between device enumeration and /dev availability, and *mounting a
filesystem*. very different things. train yourself on this before
you go any further, and definitely *DoubleCheck* what you are doing
if you get as far with this that you are at the point of being about
to do a 'dd if=/dev/sdc of=/home/me/mybackupofbaddisk.dd bs=1024'
sort of command, to build a disk image to operate on ..
btw, in case you don't know this about me, i've been a filesystems
guy since 1985. i once recovered a 640meg database that was worth
millions before it was corrupted by an idiot system administrator
doing something very similar to what you've done, but it took me
weeks and i had to write custom filesystem code to extract things out
of it. i did the same thing for the Yamaha SFS filesystem being used
in various of their products (disky), and i've had far too many burnt
fingers from this experience: i've been in the position you're in.
i'm quite willing to help you understand just how much of a mess you
are in, and give you clues how to get out of it ; but you must listen
to this bit of hard-won advice: be very, very careful, in making
assumptions about your understanding of whats going on. you got into
a mess with such assumptions already. you should be questioning
yourself more than you are questioning the system in front of you;
only with such an attitude can you make progress.
the one glimmer of hope that you have, beyond all other problems, is
that when you initialized the drive (horribly) it probably only
overwrote a couple of blocks worth of data - 4 at the maximum
(1024bytes per block, or 512, depending on your drive geometry),
which means that there are all the old blocks, with the old data,
still on the disk - just inaccessible to you, because the drive has
had its maps reset. if you can get the /dev node entry, and do a raw
block copy, you may still be able to extract *some* info from the
disk image .. but this is a really long process, and you will have to
write code - or hire me, or someone like me - to do the grunt work. ;)
;
--
Jay Vaughan
More information about the music-bar
mailing list