dd disaster on top of mounted filesystem. never mind.

[1clue]

Hi.

I have a broken system. I was already booted into system rescue cd. I have a failed OCZ Vector 150 hard disk, bought at the beginning of the year. (!!!!)

I downloaded an iso to re-install on another hdd, and downloaded it into a hard disk with backups on it. Sorry I can't show you screenshots or text because I'm on a different computer right now.

Anyway, here's the story:

1. /dev/sde is a 16g flash stick.
   
2. /dev/sdf is a 1.5t sata drive with backups on it, /mnt/backups
   
3. I mounted and saved the iso file to /mnt/backups/file.iso
   
4. I used disk destroyer and wrote the iso image to /dev/sdf, which is my backup drive!
   
5. The filesystem is still mounted.
   
6. I made a filesystem on a raid set to copy off data, but it fails on some files with 'cp: cannot stat '...': Structure needs cleaning.
   
7. I seem to be getting much of the data off though.
   

So the question: Since the drive is still mounted, is there some way to restore the existing junk that was overwritten by the iso?

This is my workstation, it's pretty important since I can't earn money until this gets fixed.

Thanks.

[frostschutz]

No. But if it's backups, just re-do the backups.

[szatox]

[1clue]

I still have the 'backup of the backup' going, but it seems based on the errors in the console that most of this was music backups. I have all that on my regular drive.

I knew the answer to this, I just hoped that somehow it would be different now.

I haven't had trouble with disk destroyer in years, now I made an especially stupid mistake.

It seems everything I lost is recoverable though, so it's no big deal.

It's just the install iso, not big at all. I didn't pull in stages since that can be gotten once I'm booted.

[1clue]

It's a drag, because for a tiny 200 mb iso file I lost over 250g of data.

It's too bad I can't somehow rebuild the directory structure which was overwritten from what's in memory (I can still see the files on the filesystem) and get more data back.

I realize some data will be actually gone, but I think the catalog is what's overwritten mostly.

[Akkara]

If you have most things backed up but not all, and you need to recover what you can, you can try to piece together the files "manually". The steps would go something like this:

• Read your backup files one 4096-byte block at a time, compute a hash for it (md5 or similar). Sort it.
  
  
• Read your to-be-recovered hard disk, also one 4096-byte block at a time, compute hashes for those, too. Sort them.
  
  
• From those two lists you can now know what blocks on the hard disk correspond to stuff you already have elsewhere. Those can now be marked "done".
  
  
• Everything else that doesn't match either belongs to a file to be recovered, or is a free block that once held something but got removed
  
  
• Blocks with lots of 0's in them are either empty, or part of the inode structure, or an executable/library of some kind. They can be ignored during the first pass of the following:
  
  
• Of the remaining blocks, scan for known headers (a ".mp3" file starts with a certain signature, likewise for flac and similar). Look for the larger media files first (it whittles the list down faster) or start with documents you need the most
  
  
• Once you have a block that's a known start for a mp3 file, find what comes after it. Basically, try concatenating each trial block to the end of the known start-of-mp3, and decoding it. If the decode processes past the 1st block without error, you now know that B follows A.
  
  
• Do similar for other types of files, testing, again, using a program that can read the format to know when the two puzzle pieces fit.
  
  
• All this is very time-consuming. Use of a good scripting language (probably Python) is recommended
  

Good luck!
_________________
Many think that Dilbert is a comic. Unfortunately it is a documentary.