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