hi,
I don't understand how this could have happened by accident.
lvm2 provides strong detection of duplicated devices.
It also detects older metadata.
that's what also puzzles me, since I've never had any issues in this
regard before.
So you would have to put in 'exact' but just old 'copy' of your device
and at the same time drop out the original one - is that what you've
made ??
no. this is what happened: (from memory)
/dev/sda5 = only PV containing vg_sh64
about 2 months ago:
pvcreate /dev/sdc1 (temp. HD)
vgextend vg_sh64 /dev/sdc1
pvmove vg_sh64 /dev/sda5 (move VG from old to temp HD)
vgreduce vg_sh64 /dev/sda5
- replace "old" sda with a new, bigger one
- create same partition layout
pvcreate /dev/sda5
vgextend vg_sh64 /dev/sda5
pvmove vg_sh64 /dev/sdc1 (move everything back to new HD)
vgreduce vg_sh64 /dev/sdc1
what I *DID FORGET* then was to issue "pvremove /dev/sdc1"
a few days ago, I inserted the old temp HD sdc into the SATA hot swap
bay and powered it on. shortly after that the system behaved strangely.
issued "dmesg" and saw a lot of error messages regarding SATA.
unfortunately, memory is blurry from then on since I entered panic mode.
Did a graceful shutdown though (closed all programms, executed
"poweroff"). from this moment on, VG on /dev/sda5 was gone.
can't rule out that powering on sdc in the hot plug bay caused havoc on
the SATA bus, just when lvm was doing some housekeeping.
VG & LV are just 'terms' - there is no 'physical-conte
lvm2 provides command: 'vgcfgrestore' - which can restore your older
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
thanks for the information (also to Roger). I managed to recover a
promising LVM text file from lost+found on the temp disk. will try to
restore it as soon as I'm back home again.
thanks - and wish me luck ;-)
_______________________________________________
linux-lvm mailing list
linux-lvm@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
