Hai ..
I had three linux server installations crashed in a weeks time .I am using RC9.0 distro..I do doubt now whether RC 9.0 is sufficient as server installaton.
After reebooting during a power failure its showing error message lke
"Checking root file system
Contains a file system with errors
Unattached Inode 64898
run fsck without -a or -p options...etc etc..

Two of my linux had the same error after power failure other one was showing /proc errro r or something like that.

I ve tried all options like fsck without -a and -p and all but of no use
and i had to reinstall linux in the first two cases and i lost all the data.Is there a solution for this .Should i do the same i mean reinstallation for the third one also which got crashed today.Had anyone gone thru a similar situation...

Plzzzzzz help

With regards
Hari

To answer your question, Linux is at least as good as any other operating system I've seen at handling power failures (when correctly configured).

The only real way to protect any system from a power failure (regardless of the OS) is an uninterpretable power supply (UPS). However, if you're worried about data integrity then you can use the sync option for partitions in /etc/fstab. This will cause Linux to write all data to the partition on every write, without using write-ahead caching. Using sync will slow down your filesystem, which is why it isn't enabled by default.

It is not at all normal to have to reinstall the complete system after a power failure. Occasionally you may find that a system file becomes damaged, but then you just have to reinstall that one file (or its package).

Relational Databases like MySQL or PostgreSQL will cope with power failures by rolling back to the start of the transaction that they were executing when the system crashed. “Serious” data servers tend to use relational databases (mainly) for this reason. If you have critical data that isn't in a database, then I suggest putting it in a sync partition of its own; that way if you have to reinstall then you can keep that partition and all the data on it.

Thanx for ur reply..

But sir to reinstall any package or anything like that,we ve to knowwhick has got corrupted,that information we r not getting..bcs its showing error in root file system...which package should i reinstall..Why fsck option doesnt work well..I think iam trying this option not properly.Culd u plz tell me how exaclty i can recover from a crash ian a similar condition..

The error message “Unattached Inode” means that a file has been created and written to but has not been attached to the directory structure. In this case, it can't be a system file (unless you've tried to delete one).

Normally, you would expect fsck to fix this type of problem. The file itself will be created in the /lost+found directory, but because there is no directory entry for this file, it will not have the right filename.

You'll know if a system file is damaged because a) your computer won't start or b) a service won't start during start-up.

In case a), boot off a rescue disk and trace the boot process through to the point where the system failed to boot. Then reinstall the package that it was trying to start (normally, this will be the kernel). If it didn't boot at all, reinstall the bootloader.

In case b), reinstall the package that failed to start.

In either case, if you reinstall using then you should expect your data to remain in tact (though this may depend on the package).

Another option is to keep backups of your filesystem images, and then restore the entire filesystem in the event of a crash. This isn't ideal as you lose data back to the previous backup, but it's likely to be the solution with the fastest recovery time. In any case, you should always keep regular backups in case of a catastrophic failure, such as a hard disk dying.

Edit: If you're using RPM, then you can use the console command: to go through each of your installed files and check if any of them have been modified against the installed version. But note that being modified isn't necessarily a filesystem fault; for instance, configuration files often get changed when you configure things.