atom feed23 messages in com.redhat.linux-lvmRe: [linux-lvm] Using LVM Mirroring t...
FromSent OnAttachments
Ambrogio De LorenzoSep 16, 2009 6:59 am 
André GillibertSep 16, 2009 8:05 am 
Ambrogio De LorenzoSep 16, 2009 9:47 am 
Brian J. MurrellSep 16, 2009 9:58 am 16, 2009 11:19 am 
Ambrogio De LorenzoSep 16, 2009 12:03 pm 
Ambrogio De LorenzoSep 16, 2009 12:15 pm 
Brian J. MurrellSep 16, 2009 12:49 pm 
André GillibertSep 16, 2009 1:03 pm 
Ambrogio De LorenzoSep 16, 2009 1:22 pm 16, 2009 1:33 pm 
Kai Stian OlstadSep 16, 2009 3:03 pm 
Bryn M. ReevesSep 17, 2009 2:57 am 
Stuart D. GathmanSep 17, 2009 8:06 am 
Brian J. MurrellSep 17, 2009 8:34 am 
Stuart D. GathmanSep 17, 2009 3:49 pm 
Les MikesellSep 17, 2009 4:26 pm 
Brian J. MurrellSep 17, 2009 4:48 pm 
Stuart D. GathmanSep 17, 2009 5:57 pm 
Sven EschenbergSep 17, 2009 6:51 pm 
Stuart D. GathmanSep 17, 2009 6:55 pm 
Mark H. WoodSep 18, 2009 9:05 am 
Stuart D. GathmanSep 18, 2009 12:12 pm 
Subject:Re: [linux-lvm] Using LVM Mirroring to obtain a usable backup
From:Stuart D. Gathman (
Date:Sep 17, 2009 8:06:44 am

On Thu, 17 Sep 2009, Bryn M. Reeves wrote:

If you don't want to muck about making manual changes you might be better off creating a new LV and mirroring the data with dd or some other block-level tool.

Using dd from a snapshot does not help the OP. He says the dd will take 5-6 hours, and he needs a backup of the system *just before* the upgrade, not hours before. The rollback also needs to be quick.

A snapshot with dd does the "instant" backup part ok, but rollback requires 5-6 hours to copy the snapsnot to a normal LV.

The OP is correct that creating and breaking a RAID1 mirror does what he needs. Apparently, LVM does not currently support this, although it could be done with dmsetup.

I always build my VGs on md* devices.

My suggestion:

1. Add another disk, create partitions for software RAID1 (md) on the new disk with missing mirrors, and size <= existing non-md PVs.

2. Make the md device(s) into LVM PVs, add to volume group.

3. Migrate your LVs to the md PVs.

4. Remove non-md PVs.

5. Turn non-md partitions into md RAID1 partitions, and attach (hot add) to the md devices created in step 1.

6. Wait for syncronization to complete.

7. Shutdown, remove one of the disks, and do the upgrade. (If you don't remove the disk and use mdadm to break the mirror, you'll have a "hardware clone" which duplicates the VGIDs, and you'll need to run the importclone script to rename+reUUID the clone.)

Alternate plan B for the paranoid:

Add *2* new disks, set up RAID1 md partitions with up to 3 mirrors, 2 active, pvcreate, add to VG, and migrate LVs to the RAID1 PVs. Add 3rd mirror, synchronize, then physically remove or break mirror and importclone. This ensures that your data always has at least 2 copies.

Alternate plan C for the brilliant:

Create new lvm command to clone LVs by creating a mirror and then breaking it. This is a good complement to a snapnot. A snapsnot can be taken "instantly", but take a long time to rollback (by copying to another LV). A clone takes a long time to synchronize, but is current as of the when the mirror is broken and can be used immediately as a real (non-snapsnot) LV for rollback or other purposes.