My sincere thanks to :
Chris Marble <cmarble@orion.ac.hmc.edu>
John Stoffel <jfs@fluent.com>
Raymond Morsman <raymond@iway.nl>
Trevor Paquette <tpaquett@aec.ca>
Rich Kulawiec <rsk@itw.com>
Matthew Stier <mstier@hotmail.com>
Paul Kanz <paul@icx.com>
Larry Williamson <larry@mitra.com>
Reto Lichtensteiger <rali@meitca.com>
"Marc S. Gibian" <gibian@stars1.hanscom.af.mil>
Extra short:
Unanimous verdict : go http://www.exabyte.com/
(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 :
ftp://gatekeeper.dec.com/pub/usenet/comp.sources.unix/volume6/unrm.rm
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 )
AAA
From: "Marc S. Gibian" <gibian@stars1.hanscom.af.mil>
>> 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
Marc S. Gibian
Telos Comsys phone: (617) 377-6350
PRISM/TFS email: gibian@stars1.hanscom.af.mil
AAA
From: Reto Lichtensteiger <rali@meitca.com>
<> 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/libc.so.X.y (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!
Reto
--
R A Lichtensteiger rali@meitca.com -or- rali@world.std.com
http://www.meitca.com/ITA/People/rali
"Yes, you're doing things right, but are you doing the right things?"
"Nope. I'm just doing something dumb fast."
AAA
From: Larry Williamson <larry@mitra.com>
I am certain that you are simply out of luck. There is no record kept
of the file system state after an rm.
AAA
From: Paul Kanz <paul@icx.com>
Fedor-
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
______________________________________________________________________________
Paul Kanz
System Administrator
Interconnectix, Inc.
10220 SW Nimbus Ave, Building K4
Portland, OR 97223
Email: paul@icx.com
Phone: 503.684.6641
Fax: 503.639.3469
______________________________________________________________________________
AAA
From: Matthew Stier <mstier@hotmail.com>
No luck.
The Unix filesystem structure does not permit it.
--
Matthew Stier
mstier@hotmail.com
---------------------------------------------------------
Get Your *Web-Based* Free Email at http://www.hotmail.com
---------------------------------------------------------
AAA
From: Rich Kulawiec <rsk@itw.com>
>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.
---Rsk
Rich Kulawiec
rsk@itw.com
AAA
From: Trevor Paquette <tpaquett@aec.ca>
Unless you have a backup tape.. there is nothing that you can do. Sorry.
--
Trevor Paquette |MetroNet Solutions Inc. |Work:(403)543-2355
TrevorPaquette@mcc.net | 2700, 421 7th Ave SW | Fax:(403)543-2854
http://www.nsci.net | Calgary, Ab, Canada |ICBM:51'05"N/114'01"W
Senior Unix Network Architect| T2P 4K9 |Mind:In the Rockies
AAA
From: Raymond Morsman <raymond@iway.nl>
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 ?
Simon
AAA
From: John Stoffel <jfs@fluent.com>
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
John Stoffel - Unix Systems Administrator - Fluent, Inc.
jfs@fluent.com - http://www.fluent.com - 603-643-2600 x341
Kill your Television
AAA
From: Chris Marble <cmarble@orion.ac.hmc.edu>
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, chris_marble@hmc.edu
My opinions are my own and probably don't represent anything anyway.
-------------------------------------------------------------------------
With best regards
Fedor Gnuchev
mailto:qwe@ht.eimb.rssi.ru
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:48 CDT