Date: Fri, 18 Feb 2005 12:43:45 -0800 From: "Thomas Foster" <tbonius@comcast.net> To: <freebsd-fs@freebsd.org> Subject: UFS2 Recovery Questions Message-ID: <00f201c515fa$8caef250$4300a8c0@home.lan>
next in thread | raw e-mail | index | archive | help
Please excuse me if this is not the correct forum in which to ask this question and please try to bear with me. I was hoping to understand a few things about attempting to retrieve information from a drive on my FreeBSD 5.3 system. I recently was rearranging my web server content and accidentally removed a symbolic link recursively root@host # rm -rf music The music link pointed to a directory that existed on a spserate drive mounted as /storage music -> /storage/Music/Mp3s I immediately unmounted the drive in question and started to comb through resources looking for any utilities in attempt to recover this data. I had not been able to install my DDS4 Tape Backup system yet, as it had not arrived yet.. so restoring from backup is not a solution. I discovered various tools including the Coroner's Toolkit, and of course.. Sleuthkit. Sleuthkit was very well documented and seemed to offer some insight into the possibility of recovering the music files in question. I immediately went to work installing sleuthkit from FreeBSD ports, and even attempting to get Autopsy running (though I believe the port is broken because I get a warning telling me the sleuthkit executables were not found). I found documentation on the sleuthkit website about data recovery: http://www.sleuthkit.org/sleuthkit/docs/ref_fs.html Now, the Manual Unix File Recovery Section gives some very helpful information in tracking down the directory in question. When combing through the disk itself.. I find the directory I am looking for: root@host # fls -r /dev/ad1s1d | grep Mp3s + d/- * 8007680: Mp3s This looks promising.. it looks like the associated inode for the Mp3s directory is located at 8007680. I scoured the whole drive and could not see any files under that directory though.. this might might be a problem. root@host # fsstat /dev/ad1s1d Group 340: Last Written: Sun Feb 6 16:14:14 2005 Inode Range: 8007680 - 8031231 Fragment Range: 31989920 - 32084007 Super Block: 31989960 - 31989967 Group Desc: 31989968 - 31989975 Inode Table: 31989976 - 31992919 Data Fragments: 31989920 - 31989959, 31992920 - 32084007 Global Summary (from the superblock summary area): Num of Dirs: 1 Num of Avail Blocks: 7280 Num of Avail Inodes: 23550 Num of Avail Frags: 7 Local Summary (from the group descriptor): Num of Dirs: 1 Num of Avail Blocks: 7280 Num of Avail Inodes: 23550 Num of Avail Frags: 7 Last Block Allocated: 32061400 Last Fragment Allocated: 32061400 Last Inode Allocated: 8007680 Awesome... i think... there are the inode ranges... but where are the block ranges listed in the documentation..? Also.. I comb through the dates, and it appears that this was the last write to the drive... so I assume that is when i deleted the directory. root@host # istat -b 2 /dev/ad1s1d 8007680 inode: 8007680 Not Allocated Group: 340 uid / gid: 65534 / 0 mode: ---------- size: 0 num of links: 0 Inode Times: Accessed: Sun Feb 6 16:12:08 2005 File Modified: Sun Feb 6 16:13:44 2005 Inode Modified: Sun Feb 6 16:13:44 2005 Direct Blocks: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Well this doesnt look good... 0 direct blocks.. i don't see this covered. Now the documentation explains that I should image the inode addresses for the group in question.. but the example given is an Ext3 file systemm which contains the information: Group: 1: Inode Range: 15393 - 30784 Block Range: 32768 - 65535 Super Block: 32768 - 32768 Group Descriptor Table: 32769 - 32769 Data bitmap: 32770 - 32770 Inode bitmap: 32771 - 32771 Inode Table: 32772 - 33252 Data Blocks: 33253 - 65535 I do not have a block range listed for UFS, and was curious if I should "dls" the Inode range listed? Keep in mind that this dive is not mounted... and has not been altered since the time of the directory deletion. I am anxious to use "foremost" to attempt and recover the files via their hex header and footer information. I setup my foremost.conf with the required information: mp3 n 30000000 \xff\xfb\x92\x04\x00\x00\x00\x00\x00\x69\x05\ \xa4\x00\x00\x00\x00\x00\x00\x34\x80\x00\x00 Now the questions is.. are the files even recoverable? Is this a lost cause? Any additional information required, any comments or suggestions, anything would be helpful. I thank you for your time in the matter. Thomas Foster http://www.section6.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00f201c515fa$8caef250$4300a8c0>