UFS2 Recovery Questions

[Thomas Foster]

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 at 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 at 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 at 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 at 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