On Mon, Jun 07, 2010 at 08:41:58AM CEST, "Andrew M.A. Cater" <amaca...@galactic.demon.co.uk> said: > On Mon, Jun 07, 2010 at 01:12:36AM +0000, Hendrik Boom wrote: > > On Mon, 07 Jun 2010 00:53:20 +0000, Hendrik Boom wrote: > > > > > On Tue, 01 Jun 2010 11:38:28 +0200, Merciadri Luca wrote: > > > > > >> Andrew M.A. Cater wrote: > > > > > >>> If you don't unmount it, e2fsck will complain. If need be, boot from a > > >>> rescue disk to do so - but I'm assuming that it's not the root (/) > > >>> filesystem, or you wouldn't have got this far. > > >>> > > >> It will complain, but will it impede its `functioning'? > > > > > > It could impede its functioning if anything at all is written to the > > > disk while it is being checked. I can imagine it resulting in > > > everything from nothing to minor problems to indescribable chaos. > > > > > > Don't go there if you value your data. > > > > And, of course, although I risk sounding like a broken record for saying > > this yet again, when you've got this fixed, make sure you have a backup > > of all your data. > > > > But if you already have a backup, don't overwrite it with anew one until > > you've fixed the problem and are sure that what you're backing up is > > correct. It might even be worth dong a diff --recursive --brief (or > > something similar depending on how your backup works) between your file > > system and your backup and checking that the files that have changed are > > the ones you expect to have changed... > > Further to this: a RAID is no infallible substitute for a backup of critical > data. > A dying controller can write rubbish to your disks silently for days - even > if you just get a straightforward controller failure, you then have to treat > all data > as potentially suspect for corruption.
And a RAID will destroy data on all disks if asked to... In 11 years administering backups, the most common use case for recovery is "oups I destroyed the wrong file". -- Erwan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100607070238.gj11...@trusted-logic.com
