barbour@alta.Colorado.EDU (Jim Barbour) (07/24/90)
One of the users on our 300 workstation blew away a "very important file" which did not make it onto our backup tapes. Are there any unrm or block recover programs for HP-UX 6.5 or some other means to recover files marked as deleted, but whose data is still on the disk. Thanks a lot, Jim Barbour
mck@hpcuhc.HP.COM (Doug McKenzie) (07/24/90)
>Are there any unrm or block recover programs for HP-UX 6.5 or some other means >to recover files marked as deleted, but whose data is still on the disk. There's nothing very reasonable. fsdb is the supported, cryptic and somewhat dangerous method of "file system debugging". Your HP SE may have the unsupported "disked" (disk editor), which is a much better interface for examining the disk. But even aside from the complexity of finding unassociated data blocks, the real problem is that unless you stopped file system activity very soon after the file was removed, the inode and/or blocks may have already been re-used. It takes a fair amount of knowledge of file system structure to attempt file recovery. It would be hard to automate because some judgment is needed to recognize the possible pieces of the file. By the way, Unix World (7/90) mentions the Norton Utilities will be available on HP workstations this fall, including "unerase". U.W. says the way it works is to place removed files in purgatory for some amount of time, before they're actually unlinked. Thus, unerase would only be useful if invoked in advance of the mistaken remove. Doug McKenzie HP-UX Support mck@hpda OR ...!hplabs!hpda!mck
jamiller@hpcupt1.HP.COM (Jim Miller) (07/24/90)
Not really, since most everything is virtual in U*ix, once a file is
rm'ed the disc space will/may be reused, possibly immediately. Just about
everything you do does a fork, which uses more disk space, etc. So
as long as no one has done a ls, or logged out, or logged in, or ... :-(
Someone may have some tool that will help you patch a file together
specifying sectors and some such. But getting that program will use
disc space ...
Unless the file is HUGE, and it's worth the work of patching it
together with missing hunks, I'd say you S.O.L. (Sure(:-) Out of Luck)
I have my "rm" aliased to "mv $* ~/.trash" but one has to remember to
empty the trash ("rm!" invokes the real thing). That way I can recover
from accidental "rm *" (last week I wanted to "rm *.bak" and typed
"rm * .bak" by mistake). -- misc note: this is about the only exception
I have to the rule "don't alias normal command names"!
Hope I'm wrong and some white knight comes to your aid -- but don't
count on it.
jim miller
Standard disclaimer + I just use it, I'm not a HP-UX wizard.wayne@dsndata.uucp (Wayne Schlitt) (07/25/90)
In article <23848@boulder.Colorado.EDU> barbour@alta.Colorado.EDU (Jim Barbour) writes: > > One of the users on our 300 workstation blew away a "very important file" which > did not make it onto our backup tapes. > > Are there any unrm or block recover programs for HP-UX 6.5 or some other means > to recover files marked as deleted, but whose data is still on the disk. > > Thanks a lot, > > Jim Barbour the short answer is: no. you delete the file, you loose the file. forever. the long answer is: yes, in theory you can recover it. you would have had to taken the system down immediately after you lost the file and you would have had to mess around with fsdb and try to link the correct inode back into the directory tree. i believe the unlinked files are put at the front of the list of free disc blocks, if you create or extend a file, you are almost guaranteed to loose part of the file that you wanted. sorry. -wayne
guy@auspex.auspex.com (Guy Harris) (07/26/90)
>By the way, Unix World (7/90) mentions the Norton Utilities will be >available on HP workstations this fall, including "unerase". U.W. says the >way it works is to place removed files in purgatory for some amount of time, >before they're actually unlinked. Thus, unerase would only be useful if >invoked in advance of the mistaken remove. Well, actually, if the "mistaken remove" is the one the user did, as opposed to the one the Norton Utilities' daemon does (removing the file from purgatory), "unerase" wouldn't be very useful at all if invoked in advance of the mistaken remove, for obvious reasons.... Given that, I presume you meant "in advance of said daemon reaping the file".
scotta@hpcuhd.HP.COM (Scott Anderson) (08/01/90)
Like everyone else has said, unless you took precautions against the
disk space getting reused, the files are probably gone. My contribution
to the subject is how to avoid fsdb... I'll warn you however, my method
is slow, relies on you to remember a string from the file that will be
fairly unique on the entire disk, is not idiot proof, you need to be
root if your device files are set up correctly, works well only on ascii
(or other recognizable data) and that in order to reliably work will
require access to a disk other than the one that contains the file. The
advantage is that you're a lot less likely to screw up your file system
and that you don't have to have an intimate knowledge of the file
system.
Ok, here goes: I use a combination of fgrep and dd to grab the file.
First you need to find the block address of the file:
fgrep -b 'known text string from removed file' /dev/rdsk/0s0
Replace /dev/rdsk/0s0 with the character special device for the disk
that contains the removed file. Watch the output and identify which
occurrence occurs in the removed file. BTW, don't expect to be able to
fgrep an entire disk instantaneously :-).
Now that you've got the disk address (e.g. 12345), now use dd to
snag a bunch of blocks around that address in order to make sure that
you get the whole file:
dd if=/dev/rdsk/0s0 of=file_on_another_disk skip=12340 count=11
In this example, I knew that the file was around 2k long, so I wanted to
grab 5 blocks (2.5K; 1 block = 512b) of slop before and after the
address that was reported by fgrep (skip=address-slop; count=2*slop+1).
Instead of /dev/rdsk/0s0, you should use the same character special file
you had fgrep work on. Make sure that you don't flip the if= and of=
around: can you say trash the file system? Saving the output is where
you need a second disk (or I guess you could just dump the stuff out to
a tape). If you put the output on the same disk as your removed file,
there's a chance (I don't know the probability) that your output will
blow away the data you're trying to recover. One last thing about dd:
it was designed as a tape utility; as such it doesn't use seek to get
the block you specify with the skip parameter: it just keeps reading
until it's read the specified number of blocks. This means that you
shouldn't expect this operation to go any faster than the fgrep did.
For those advanced users, you can use a larger block size (bs=) in order
to speed it up; make sure you recalculate skip= and count= based on the
new block size. If someone knows a better way or has written the short
program necessary, speak up.
The file that you have now will have a bunch of extraneous stuff on
both ends of it (probably nonASCII). Go in with an editor and remove
the stuff from both ends and you've got your file back. If the editor
you want to use doesn't deal with nonASCII data very well, you may want
to pipe your file through cat -v before editing it.
I suppose I should add that I'm not speaking for HP and that I have
nothing to do with HP-UX except that I use it as a tool to get my job
done.
Scott Anderson
An RTEsian and proud of it...
Hewlett-Packard
ARPA: scotta%hpdsorte@hpsde.HP.COM Data Systems Operation
UUCP: hpsde!hpdsorte!scotta 11000 Wolfe Rd. MS 42UN
408-447-5219 Cupertino, CA 95014