istvan@hhb.UUCP (Istvan Mohos) (08/02/90)
peram@cs.tamu.edu (Suresh B Peram) writes: > I have lost a whole directory containing > important information while running a shell-script... > I want to know where I can find the Super Block. Well, you're not the first one this happened to. Here is what someone else had to say about it a while back (about a year ago): :Subject: Re: Can you recover deleted files in Unix ?!? :From: kellow@ndcheg.cheg.nd.edu (John Kellow @ Dep't of Chemical Eng., Univ. of Notre Dame) :(100 lines) More? [ynq] kellow@ndcheg.cheg.nd.edu (John Kellow) writes: : :>I need some help. Maybe this questions has been covered but I can't :>remember seeing anything about it before. Is there any way to recover :>deleted files in System V.2 Unix? I typed rm * when I thought I was :>in the /tmp directory but guess where I was - that's right, my home :>directory. Unfortunately there were some important changes that :>haven't been backed up. I was the only person using the computer at :>the time, and I immediately unmounted the file system. My manual :>entry for rm says something to the the effect that if a directory :>entry was the last link count for a file then the file is destroyed - :>does this mean data and everything? Please tell me it isn't so. I'll :>be eagerly awaiting any replies. : :Well, in answer to my own question - I did recover the important data :that I had deleted. I guess the answer would be no, you can't :"undelete" files in SYSV.2 Unix but you can recover individual blocks :of data. It took a few hours of trying to decipher the manuals and :some trial and error but I think I've got it figured out and its not :too complicated (someone correct me if I'm wrong). The actual blocks :of data are not removed, only the inode entry. Since the inode entry :contains all of the information as to what blocks belong to what file :and in what order, you can't very well "undelete" the file but the :data might still be there and you can piece it back together by hand. :The names of the deleted files are not removed from the directory but :the inode number is set to zero, so all that gives you is the list of :which files were deleted. The important information is the free list. :The superblock contains a list of the 50 most recently freed blocks :and the address of the next block in the list. It seems that the last :block freed will be the first block allocated, so you have to act :fast! Luckily I synched the disks and umounted the file system as :soon as my mistake occured. One more problem is that once the 50 :entries of free blocks in the superblock are filled, the free list :will be copied into the next block to be freed, so that the free list :space in the superblock can be used again. In other words, for every :50 blocks of space freed, 1 of those blocks will be used to contain :the next block in the freelist. That means that there's a very good :chance that some of your data will be lost. Now the good news, :recovering the data is actually pretty simple (this all has to be done :as the root user): : : -Examine the Superblock of the file system with fsdb : typing 512B.p0e will give something like this: : :0001000: 248 0 15760 32 0 1066 0 3584 :0001020: 0 3583 0 3615 0 3614 0 3613 :0001040: 0 3612 0 3611 0 3610 0 3609 :0001060: 0 3608 0 3607 0 3606 0 3605 :0001100: 0 3604 0 3603 0 3602 0 2496 :0001120: 0 3675 0 3684 0 3683 0 3682 :... : : -248 is the # of blocks in the inode list, 15760 is the : number of blocks in the file system, 32 is the number of : entries in the free list and the next 50 numbers are the free : blocks (but only the first 32 make up the current list) : : -1066 is the first block in the free list and indicates the : next block in the list, so if you want to recover more than : the number of blocks in the current list(32) you would look : in block 1066 and that would contain another free list with : 50 free blocks, with the first entry pointing to the next : block in the list, etc. : : -from what I understand, block 1066 was one of the blocks : freed up but now it contains part of the free list so you : can't recover that data : : -write down the numbers of the blocks you want to recover and : use bcopy to copy those blocks into files on another file system : : -for example, to recover block 3584 type bcopy and answer the : questions: : bcopy : TO: 3584 (this makes a file called 3584 in the current file system) : OFFSET: 0 : FROM: /dev/fp003 (the name of the partion you're recovering from) : OFFSET: 7168 (my version of bcopy goes by 512 byte blocks so : I have to multiply 3584 by 2) : COUNT: 2 (2 512 byte blocks or 1 1024 byte logical disk block) : (it keeps asking FROM: so just press return twice to exit) : : -Thats it, just use emacs or vi to look at the blocks and : piece them back together, blocks belonging to the same file : should appear consecutively in the free list but you don't : know what order they should go in - thats not too difficult : to figure out with text files but I guess binary files are : another story (luckily I didn't need to recover any of those) : :Well, this explanation turned out longer than I thought but maybe it :will help someone else in a similar situation. I think most of this is :standard System V.2 but some of it may be specific to my system. I'd :appreciate any comments anyone has. Maybe there's a better way to do :this or it seems to me that you could write a simple shell script or :program to automate this procedure ( I hope I didn't go to all this :trouble if there's already something that does this!). : :John Kellow :kellow@ndcheg.cheg.nd.edu -- Istvan Mohos ...uunet!pyrdc!pyrnj!hhb!istvan RACAL-REDAC/HHB 1000 Wyckoff Ave. Mahwah NJ 07430 201-848-8000 ======================================================================
decot@hpisod2.HP.COM (Dave Decot) (08/03/90)
> / hpisod2:comp.unix.wizards / als@roxanne.mlb.semi.harris.com (Alan Sparks) / 11:06 am Aug 1, 1990 / > In article <14020106@hpisod2.HP.COM> decot@hpisod2.HP.COM (Dave Decot) writes: > > >Read the man page for fsdb(8) (or fsdb(1M)) carefully, and then practice > >removing and then restoring some other unneeded large file. > > > > What's fsdb? Filesystem debug? I run SunOS 4.0.3, and I've never seen it. > Command not found, no man page, etc. What machine, HP? Whoops. Mostly only on System V-derived systems (including HP-UX). Sorry to assume that everyone had this (useful) utility. Dave Decot
chogan@maths.tcd.ie (Christine Hogan) (08/07/90)
>Whoops. Mostly only on System V-derived systems (including HP-UX). >Sorry to assume that everyone had this (useful) utility. A similar thing has just happened here, and we don't have fsdb either. The machine has been untouched since the directory was deleted. Any suggestions ? Christine Hogan. chogan@maths.tcd.ie chogan@cs.tcd.ie
karish@mindcrf.UUCP (08/08/90)
In article <1990Aug7.153118.28729@maths.tcd.ie> chogan@maths.tcd.ie (Christine Hogan) writes: >A similar thing has just happened here, and we don't have fsdb either. >The machine has been untouched since the directory was deleted. >Any suggestions ? Whether done with fsdb or not, the task is to read the disk partition block by block, check each block to determine whether it's part of the data to be recovered, and reassemble the recovered blocks. You have to be able to recognize the blocks you want, and weed out obsolete versions that may be on the partition. Much easier for text files than for pieces of executables or binary data files. I'd write a filter to open the raw device, read out blocks and try to guess whether they're text, and feed the text blocks, one by one, to grep. Then spit out the block number for each match. If you can duplicate the functionality of fsdb to the extent of finding the inodes of the deleted files, you may be able to save a lot of trouble. Unfortunately, there'll still be some trial and error involved, because the act of deleting a file involves deleting the inode number from the directory entry where it had been associated with a file name (and, on some systems, removing the entire directory entry). -- Chuck Karish karish@mindcraft.com Mindcraft, Inc. (415) 323-9000
munir@hpfcmgw.HP.COM (Munir Mallal) (08/10/90)
>>A similar thing has just happened here, and we don't have fsdb either. >>The machine has been untouched since the directory was deleted. >>Any suggestions ? > >Whether done with fsdb or not, the task is to read the disk >partition block by block, check each block to determine whether >it's part of the data to be recovered, and reassemble the recovered >blocks. You can use adb if you have it, but will have to do a lot of math to determine offsets etc. Munir "adb does it all" Mallal
kseshadr@quasar.intel.com (Kishore Seshadri) (08/10/90)
In article <7410002@hpfcmgw.HP.COM>, munir@hpfcmgw (Munir Mallal) writes: >>>A similar thing has just happened here, and we don't have fsdb either. >>>The machine has been untouched since the directory was deleted. >>>Any suggestions ? >> > >Whether done with fsdb or not, the task is to read the disk > >partition block by block, check each block to determine whether > >it's part of the data to be recovered, and reassemble the recovered > >blocks. > >You can use adb if you have it, but will have to do a lot of math to determine >offsets etc. > I have a binary file modifier called fm that I pulled off comp.sources.misc that can be used to edit devices and binary files. Once again if you do the math beforehand this program may be of help in this situation. The devices can be edited in either hex or ascii modes and simple string searches can be handled. You should probably have a good understanding of the way the file system has been implemented before fooling with this. Kishore Seshadri ---------------------------------------------------------------------------- Kishore Seshadri <kseshadr@mipos3.intel.com> or <..!intelca!mipos3!kseshadr> "The nice thing about standards is that you have so many to choose from."