Undelete for UFS

Apparently this isn't my week. In a nice line of screw-ups I deleted the contents of my archive drive. I acted before I thought to double-check what I was doing; I blame my obnoxious neighbors for sleep depriving me with their constant racket.

The drive has a single partition with UFS and I essentially did a [font="Courier New"]rm -R /archive/*[/font]. I know there is the system call undelete(2), however I don't do any coding outside of simple shell scripts and HTML so I wouldn't know where to begin.

I know I should have backups, but no money + 500GB of data = no backups. I'd appreciate any help on this.
 
before you even think of doing anything you must backup entire drive with dd (this will make sure if you screw things even further, you can restore data to previous state, yes no available data, yet, but it lies on disk)

unfortunately this is all i can tell atm

I'll look up net, when i return from university
you can check http://daemonforums.org , i think there was similar thread
 
I appreciate it killasmurf. I did find this thread which references the ddrescue, testdisk, and photorec recovery programs. I'll be giving these a try and hopefully I'll be able to recover some of what I need.
 
Which FreeBSD version are you using? There is a new data recovery tool, appears from FreeBSD 7.0 and above only: recoverdisk. Read more here if you are interested

Also, writting a script based on move (mv) which seamlessly replaces the remove (rm) command to avoid such accidental deletion could be a good idea ;)
 
Give sleuthkit/Autopsy a swirl, both are in the ports..
You can work on that dd image you've made so you can screw around with it :)

It's actually a forensics toolkit but it will allow you to restore deleted files (if the space hasn't been overwritten yet).

http://www.sleuthkit.org/
 
way back in 2004-5 when I started using FreeBSD, I aliased
rm to just echoing "are you sure". Thereupon, to actually use
rm I am obligated to /bin/rm, and as long as I take that extra
step, it is usually expedient to add the -iv. So
/bin/rm -iv
takes about 2 seconds longer, long enough to catch maybe one or
two errors a week before they occur
 
There is a commercial utility called "UFS Explorer" for Win32 and Win64 that includes support for recovering files from many BSD and Linux file systems, including Ext3, HPFS+, NTFS, ReiserFS, UFS2 and XFS.

I gave it a spin today on a UFS2 partition and found that, compared to my experiences with recovering files from FAT and NTFS partitions, it was fairly dismal. I'd say less than a 40% recovery rate for UFS2 when I typically have NTFS recovery rates of over 90%.

The people who make the product have this disclaimer:

Unlike Windows, Linux/BSD/Unix operation system drivers clean the part of inode information after file is deleted: it fills with zero object size, object type/mode information and object allocation information. This means after file if deleted, [the filesystem] knows nothing about it.
 
The script proposed by bsddaemon is a good idea to prevent accidents in cases where your fingers are faster than your brain!

Another lifesaver:
Code:
set rmstar
in your .cshrc file will prevent terrible accidents. It would not have helped you in this case, but imagine that you had typed
Code:
rm -R /archive/ *
instead of
Code:
rm -R /archive/*
Then not only your archive would be gone, but all files rooted in your working directory! This would change a bad week into a terrible week! :e With the set rmstar in .cshrcyou would get a second chance:
Code:
 # rm -R /archive/ *
Do you really want to delete all files? [n/y]
 
Back
Top