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

Re: [linux-lvm] Best practice: metadata backup



On Tue, 7 Aug 2007, Alasdair G Kergon wrote:

> There are already copies (and backups of previous copies) on each physical
> volume (in the default configuration) and there's an automated process to deal
> with simple problems like power failure during a metadata update leading to
> disagreement between the copies.

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.

I wish I could take a sabbatical and spend a year setting up VGs,
breaking them in evil ways, and fixing the tools to intelligently
recover.  Given the nature of open source, OSS friendly employers should
offer sabbaticals for developers, like clergy and academics get.  A year
every 7 years to work full-time on whatever project (hardware or
software related) grabs their interest.

Certainly, automatically bringing all remaining LVs online after
PV failure is a must.

I've always been interested in data storage that can recover from
disaster.  I designed a database filesystem that stores a table id
in every block, so that usable tables and directories can be recovered
regardless of what portion of the filesystem is wiped out (missing records,
of course).  It has saved our customers butt several times ("No, we don't
know where the backup tapes have gone...we took them offsite like you said.
You didn't say anything about bringing them back.").

-- 
	      Stuart D. Gathman <stuart bmsi com>
    Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.


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