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:=20 Inode Range: 15393 - 30784=20 Block Range: 32768 - 65535=20 Super Block: 32768 - 32768=20 Group Descriptor Table: 32769 - 32769=20 Data bitmap: 32770 - 32770=20 Inode bitmap: 32771 - 32771=20 Inode Table: 32772 - 33252=20 Data Blocks: 33253 - 65535=20 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>