![]() |
Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
Try FTK Imager Lite. Also look into TSK (The Sleuth Kit) / Autopsy (web frontend for TSK). Was this a RAID or a single disk? Scott On Mon, Feb 4, 2013 at 11:33 AM, Rich Braun <richb at pioneer.ci.net> wrote: > I think we've all done this at some point: an rsync --delete or the > equivalent, from an empty directory to a target directory that had stuff we > didn't want to lose. > > In my case I have cron job that mirrors two systems. While swapping data > around yesterday, I forgot about this cron job and rsync merrily deleted a > couple hundred .mpg files (I have the filenames in a log, to which my cron job > deposits the verbose stdout, so I know exactly what happened and when). > > Lesson learned: obviously, I'm going to change that cron job to some sort of > sequestration method: move the files someplace before this rsync, don't ever > delete them until I manually confirm. (Anyone else have a script for that? > It'll be a bit hairy to write from scratch...) > > Now I'm hunting for a recovery tool that can scavenge these files from the > (partly) emptied-out ext4 filesystem image. > > Both 'extundelete' and 'debugfs' find nothing; they apparently look at a > journal that's apparently empty, and I don't know how to use them well enough > to force them to look more deeply. I know the content is there, though, > because (a) there were no operations done on this filesystem after the > deletion, and (b) a scan by another tool 'foremost' finds 142 of the missing > files (its default configuration can pattern-match .png files but not my .mpg > files). > > Have you ever been able to get an undelete tool to work? If not, have you > ever switched to a different filesystem so as to get better access to > accidentally-deleted data? Some of the old filesystems (mostly from DEC) were > much better at sequestering data so it stays around until new files require > use of the space. > > Meanwhile, the script-writing and script-improving *never ends*... > > -rich > P.S. This is all I got out of "undelete": > > # extundelete /dev/data01/volmytharch1 --restore-all > WARNING: Extended attributes are not restored. > Loading filesystem metadata ... 8200 groups loaded. > Loading journal descriptors ... 31971 descriptors loaded. > Writing output to directory RECOVERED_FILES/ > Searching for recoverable inodes in directory / ... > 0 recoverable inodes found. > Looking through the directory structure for deleted files ... > 0 recoverable inodes still lost. > No files were undeleted. > > > _______________________________________________ > Discuss mailing list > Discuss at blu.org > http://lists.blu.org/mailman/listinfo/discuss
![]() |
|
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |