Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Data recovery



On Sat, 26 Nov 2005 00:05:27 -0500
jbk <jbk at mail2.gis.net> wrote:

> I have had two types of experiences with system craches. The 
> first type the automatic journal recovery succeeds and the 
> boot continues as normal. In the second, the journal 
> recovery fails and you are dumped to a prompt where you have 
> to decide what tool to use. From this point I have had 
> disastrous results using fsck without rebooting with a 
> rescue disk.
Recovering the root file system is a bit different from other file
systems. When fsck runs during the boot process, the root file system
is mounted read-only and the other file systems are not mounted. It is
ok to do a full recovery on a file system that is not mounted, but not
root. The reiser fsck utility will not allow you to do a complete
repair on root unless you boot from recovery. Ext2 and ext3 do allow a
repair of the root file system when your system is running, but that
file system MUST be mounted read-only. If you try to repair a mounted
file system that is mounted as read-write, the system will write the
in-memory data back onto that file system, and then you are screwed. 
The best practice is to boot from a recovery disk and perform the
repair while the root file system is unmounted. (This is true with all
Linux and Unix systems). You can then mount that file system from the
recovery disk and check it out. 
(Make sure that your recovery disk contains the proper file system and
utilities at the same rev. of what your system is running. 

My old laptop had a bad memory chip, and it would cause my file system
to trash on occasion. Additionally, I had a failing power supply on my
home system causing similar results where I had to recover the file
systems. (And I'm no stranger to recovering commercial Unix file
systems). 

-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.blu.org/pipermail/discuss/attachments/20051126/593d4f46/attachment.sig>



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org