From: Alasdair G Kergon <agk@redhat.com>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] Best practice: metadata backup
Date: Wed, 8 Aug 2007 22:21:02 +0100 [thread overview]
Message-ID: <20070808212102.GP2064@agk.fab.redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0708081447350.23150-100000@bmsred.bmsi.com>
On Wed, Aug 08, 2007 at 03:03:38PM -0400, Stuart D. Gathman wrote:
> That's good. But I've been lurking and noticed that when things
> go disastrously wrong, and some poor admin posts here hoping for a miracle,
> the key to the miracle is having a copy of the LVM metadata somewhere for
> use with vgcfgrestore. Apparently, the PV copies are not enough for
> current tools to allow recovery from some situations.
No distribution that I'm aware of uses the existing facilities in full
to solve problems at system boot. If things aren't exactly right they
fail and leave the user to work out how to clean up the mess. There's
quite a bit of logic that could be added to the initrd/initscripts to
handle - or at least report on - certain failure situations using the
existing LVM2 features.
Secondly, by the time admins seek help, they've sometimes already made
their situation many times worse by attempting to fix things the wrong
way. Worse, they sometimes realise they did something stupid and
convince themselves they can still get sensible advice without revealing
everything they know they did. So someone providing that help needs to
try to check everything in more than one way in case relevant
information is being withheld. Mechanisms to help skilled support
engineers deal with such situations efficiently pervade the LVM2 design.
The lvm_dump.sh script is being developed to capture the essential
information about an LVM2 system, and eventually we hope to have tools
to analyse and report upon the contents of the dump. 'pvck' is also
under development to aid recovery from one class of problems.
> Certainly, automatically bringing all remaining LVs online after
> PV failure is a must.
That's an example in point. The LVM2 tools have offered facilities to
do that for several years. The distributions do not yet make use of
them.
Alasdair
--
agk@redhat.com
next prev parent reply other threads:[~2007-08-08 21:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-05 4:17 [linux-lvm] Best practice: metadata backup Stuart D. Gathman
2007-08-07 19:01 ` Alasdair G Kergon
2007-08-07 20:56 ` Stuart D. Gathman
2007-08-07 21:34 ` Alasdair G Kergon
2007-08-08 19:03 ` Stuart D. Gathman
2007-08-08 21:21 ` Alasdair G Kergon [this message]
2007-08-09 7:23 ` John Hearns
2007-08-07 21:44 ` paddy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070808212102.GP2064@agk.fab.redhat.com \
--to=agk@redhat.com \
--cc=linux-lvm@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).