Hi all

I am using SOLARIS 8 on Sun enterpris3000 server. Last night i got a file system corrupted adn some inconsistancy in the file system were shown when i run fsck -o p option.
Then i tried to fix it with fsck -F ufs -y /dev/md/rdsk/d1 option as i have given all yes response i cd not able to see the questions asked during fsck. after this phase is complete when i run fsck -o p again it shows the error inj super block or magic number so i assigned a new superblock and fix the bug.
but after that when i fount the file system it was previouly 63% full and now it is only 16% and everything is written to lost+found directory. with the inodes number of the files assigned to every files .Still aome previous files and directory mapping are not their in the lost+found directory.
I think the reson may be during fsck when it ask to clear the inodes i have given yes option to around thousands of inodes.

I am telling the exact error i was getting when i first notice the corrupted file systems.

1) i can able to creat files and directories in that file system.Once i come out of the directory and put ls or ls -al it shows nothing.
2) when i tried to delete those file and directories it will say files exists can't delete.even rm -r won't work


Now i have restored all data from last night backup. but still i want to know HOW TO RESTORE DATA FROM LOST+FOUND DIRECTORIES?

Plese SUGGEST.
Thanks and regards
Prafulla

If you are repairing a filesystem, you must run fsck on the unmounted filesystem. If you are repairing the root filesystem, run fsck while the system is in single-user mode and no other user processes are running. After repairing root, you must bring the system down immediately, without running sync, and reboot it.

Although it is technically feasible to repair files that are damaged and that fsck says you should remove, it is usually not practical.The best insurance against significant loss of data is frequent backups. If you do not have write permission to the filesystem fsck is checking, fsck will report problems but not give you an opportunity to fix them.

When fsck encounters a file that has lost its link to its filename, fsck asks you whether you want to reconnect it. If you choose to reconnect it and fix the problem, the file is put in a directory called lost+found, and it is given its inode number as a name.

try ufsrestore command to restore you data back from lost+found. I havent done with that command before. Maybe other have some idea of the syntax..

First, ufsrestore recovers files from a tape prviously written by ufsdump. It's a cool program, but it won't move stuff out of lost+found.

You can manually move things from lost+found by doing stuff like "mv /lost+found/143226 /etc/passwd" or whatever. But moving a file from one point to another point in the same filesystem never increases its size. If your disk is 16% full now, after the moves it will still be 16% full. If your disk was previously 63% full, then you are missing lots of stuff.

I never try to fix a filesystem that is this badly damaged. I would newfs it and completely reload from backup. Unless it is root, it which case I would reinstall the OS. Sorry for the bad news.

You would think that the superblock at least would be ok after a "fsck -y"; but I believe you, because the same thing happened to me a few weeks ago only on a SunOS 2.5.1 box. It may be that Sun's fsck is less than robust.

As the Size of your filesystem has reduced to an incredible low value,
Lot of Data (files & directories) might be lost.

For restoring the Files & Directories that have got stored in the lost+found
directory read the below mentioned lines.

--------------------------------------------------------------------------------------

When FSCK is performed on a FILE System,

example : fsck -o f /dev/rdsk/c0t0d0s4
where /dev/dsk/c0t0d0s4 is mounted on /export

And if FSCK encounters any problem with the FileSystem SuperBlock Entries,
It prompts for a confirmation to rectify the problem, When Confirmation is provided,
FSCK tries to rectify the problem either correcting the Entries in the SuperBlock
or by moving the files[having the problem] into the /FileSystem/lost+found Directory.

example : ** Phase 3 - Check Connectivity
UNREF FILE I=788 OWNER=root MODE=100644
SIZE=19994 MTIME=Jan 18 10:49 2001
RECONNECT? y

In this case the file with INODE Number 788 is moved into the /export/lost+found
directory as

# ls /export/lost+found
#788


For Restoring the file in /export/lost+found into /export perform the below mentioned
tasks :

# ls /var/tmp/c0t0d0s4*
/var/tmp/c0t0d0s4_log

View this file to know the Correct File Name & Path for the corresponding file stored in the
/export/lost+found Directory with the INODE_Number as the FileName.
And then MOVE or COPY the file from /export/lost+found Directory into the Correct Path
mentioned in the LOG File.

--------------------------------------------------------------------------------------

Try this it will work fine. Good Luck.

fsck does not fix or protect your data as a first priority, it's main purpose is to keep the file system in a consistanmt state. It is possible for a box to go down hard with a bunch of open files, and to lose data completely.

Good luck, and remember, good backups are your friend.