SUMMARY: Again - 'unerase'-like utility???

From: Fedor Gnuchev (
Date: Tue Mar 11 1997 - 10:47:54 CST

My sincere thanks to :

Chris Marble <>
John Stoffel <>
Raymond Morsman <>
Trevor Paquette <>
Rich Kulawiec <>
Matthew Stier <>
Paul Kanz <>
Larry Williamson <>
Reto Lichtensteiger <>
"Marc S. Gibian" <>

Extra short:

        Unanimous verdict : go

(and between lines - do not make yourself a fool : never share root password,
        even if owner insists - then plainly refuse ANY deal )

Also - there is an attempt to help hasty users to recover accidentally
rm'ed files, which as I understood is now part of HP-UX :
 a substitution for original rm, not filesystem-level - trash-bin recovery
 works same way as filemgr's wastebasket. Counterproductive if you want
 to remove file taking more than half of available space on $HOME fs.


Short history and summary from answers:

At first I've to confess for a little cheating - system in question was
PC-based running FreeBSD. That's technicaly important point - it have
(had ;-) *statically* linked rm. Sorry for cheating :-)

Since it was read between lines - another *my* fault : I'd surrendered to the
owners demand to know root password (even been fully aware of consequences).

Meanwhile I'd reinstalled the system on another disk, with same root password
and as close configuration as I'd been able to reproduce from the journal.
Another box was setup to monitor/filter traffic - and to no surprise I've
a log of break-in and same 'rm -rf /'.
Technical motivation was to determine nature of disaster (since rm on
FreeBSD have an option to overwrite a file with 3 diffirent bit patterns),
non-technical :
to prove to happy owners of the machine that violation of common sense rules
is commonly punished. You'd laugh - they had root password in big letters on
a sticker placed right on the monitor ... since they thought that after
installation and fine-tuning there is nothing more to do, owners asked for
root password in exchange for the installation fee.
  ---done with policy---

The damaged drive was taken to another system and each filesystem had been
dd'ed to separate files.

Using supplied suggestions I'd inspected contents - and then looked through
source for unlink : oops! it basicaly cleans up inode lists!!!

So - even with all data been physicaly intact, it is a job for the next
life to link Hupty-Dumpty again. While it was relatively easy to recover
short text files main prize was in zip's with reports - hopeless task ...

Side note: On Sunos/Solaris that silly 'door-bang' is stopped by dynamicaly
linked rm - that is all filesystems after /usr/lib would remain intact
(see response from Reto Lichtensteiger).
And (provided that important data is on diffirent fs) that saves some pain.

Still nothing can help in absense of common sense and working tape backup :-)

 ------slightly edited answers (in no particular order)-----
 (hope I've not spilled the baby with little common water)
 ( replies are delimited by AAA )


From: "Marc S. Gibian" <>

>> My backup tape drive is broken (well, bad things tend to happen well
>> synced), so the question is - assuming that no more harm than 'rm -rf /'
>> was done, what are my chances of recovering filesystem(s) back?

pretty much zero.

You must remember that Unix filesystems are much more sophisticated than good
old MS DOS. While DOS keeps a single free cluster chain, Unix does things like
scatter file sectors across a drive to optimize access times. This has the
added impact of quickly destroying any deleted information.

There ARE data recovery companies that for a lot of money, and with a lot of
time, can reconstruct some fraction of the data on a deleted or damaged Unix
filesystem. But, I would hate to rely on going that route. Unfortunately, it
sounds like you don't have any more attractive options.

This is why you need to treat Unix backups as one would mainframe backups in
the old "glass machine rooms." I know its hard to get funds for things like
keeping the tape drives working, buying enough tapes to do appropriate backups,
and even better, buying a commercial grade backup facility to avoid depending
on (ufs)dump. But, after you go through a disaster or two, such as you have
right now, the people controlling the budget are a bit more understanding.

Sorry I can't offer any more immediate help...


Marc S. Gibian
Telos Comsys phone: (617) 377-6350
PRISM/TFS email:


From: Reto Lichtensteiger <>

<> got a system which (I hope) was 'rm -rf /' by offended employee. It
<> worked as print-server and when it stopped printing someone in the
<> group that use it calmly rebooted the wreck - and it stopped on boot.

I once did an rm -rf on purpose to see what would happen. The system
stoped functioning after the rm deleted /lib/ (which makes
sense as rm is dynamically linked as well ...)

Lack of system libraries will casue the reboot to fail as well :-)

Try booting the system from CDROM and mounting the user partitions
read-only to see if the rm got there at all -- you may find they haven't
been touched.

Do NOT fsck them first -- if they are intact, then fsck the partitions.

Good Luck!


R A Lichtensteiger -or-
    "Yes, you're doing things right, but are you doing the right things?"
    "Nope.  I'm just doing something dumb fast."


From: Larry Williamson <>

I am certain that you are simply out of luck. There is no record kept of the file system state after an rm.


From: Paul Kanz <>


My understanding is that there are no 'unerase' utils for 4.2 or ufs filesystems. If you had HP-UX, you would be in luck. < and from continued discussion > The utility is called 'unrm'; I don't remember the location, but if you search for it, you'll find it.

It works very similar to DOS utilities that look for inodes that have been marked as free, but not have been allocated. It does not unerase everything, but it helps get back most of the data.



Paul Kanz

System Administrator Interconnectix, Inc. 10220 SW Nimbus Ave, Building K4 Portland, OR 97223 Email: Phone: 503.684.6641 Fax: 503.639.3469 ______________________________________________________________________________


From: Matthew Stier <>

No luck.

The Unix filesystem structure does not permit it.

-- Matthew Stier

--------------------------------------------------------- Get Your *Web-Based* Free Email at ---------------------------------------------------------


From: Rich Kulawiec <>

>Although I'm sure I'd seen somewhere mention of 'unerase'-like utility, >in the moment of need (&& panic) it escapes me. I'd not recorded it when >there was no great immidiate need :-) - biting elbows now ...

There is no "unerase" utility, although sometimes in cases of extreme need (and expense) it's possible to recover blocks of some files from the free list of the affecte filesystem -- but doing so requires extensive knowledge of the filesystem's internal structure and a lot of patience. It also gets harder to do if (a) the system is rebooted and/or if (b) the system is allowed to continue to run. There are some tales of this in the Sun-Manager's archives; basically the technique is to grab all of the blocks that are in the filesystem but aren't currently allocated to any file/directory, and then sort through the mess. On a filesystem of any appreciable size, this is a monumental job.

In short, if you proceed, you're likely to expend huge amounts of effort for very little possible reward. It is probably a more cost-effective use of your time to rebuild the machine and cause the appropriate data to be regenerated.


Rich Kulawiec


From: Trevor Paquette <>

Unless you have a backup tape.. there is nothing that you can do. Sorry.

-- Trevor Paquette |MetroNet Solutions Inc. |Work:(403)543-2355 | 2700, 421 7th Ave SW | Fax:(403)543-2854 | Calgary, Ab, Canada |ICBM:51'05"N/114'01"W Senior Unix Network Architect| T2P 4K9 |Mind:In the Rockies


From: Raymond Morsman <>

Fedor, I am sorry to give you bad news, but that is it ! Game over, once a file from a Unix filesystem has been deleted, it IS deleted. No way can it be recovered. There are some utilities that can be installed to gaurd against this sort of thing, but they have to be running on the system before you delete files, these things won't work retrospectivly. (They are a version of rm which moves files to a /trash directory rather than actually delete them ). Don't waste your time trying to recover this, re-install th OS and put it down to experience. Also, maybe tighten your security ?



From: John Stoffel <>

Fedor> got a system which (I hope) was 'rm -rf /' by offended Fedor> employee.

Run, not walk, and change all the root passwords on your machines to something only _you_ know. I assume you are the Sysadmin, why do other employees need root access? If they need to run special commands, you can give them access to them via the 'sudo' public domain package.

Fedor> It worked as print-server and when it stopped printing someone Fedor> in the group that use it calmly rebooted the wreck - and it Fedor> stopped on boot. Only then they called for help. And "as Fedor> usual" - most nessesary files(reports,etc) were created after Fedor> last backup had been made.

Well, if your backup drive is broken, you're going to have a tough time doing a restore from the last good backup of root, which would get the system up and running again, so you could then start making all the changes again to restore it to full operating condition. Fedor> My backup tape drive is broken (well, bad things tend to happen Fedor> well synced), so the question is - assuming that no more harm Fedor> than 'rm -rf /' was done, what are my chances of recovering Fedor> filesystem(s) back?

You pretty much have no hope of getting the files back without _alot_ of work. It's probably easier and faster to just do a full re-install of the OS and go from there.

There are ways to get files back, but since you have to go and much about on a really really low level of the disk structures, it's probably not worth it.


John Stoffel - Unix Systems Administrator - Fluent, Inc. - - 603-643-2600 x341 Kill your Television


From: Chris Marble <>

My best suggestion is to use "dd" to copy the entire disk to a file on another disk and then use strings to extract out what you can/ -- Chris Marble - HMC UNIX Systems Manager, My opinions are my own and probably don't represent anything anyway.


With best regards

Fedor Gnuchev

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:48 CDT