[linux-lvm] Volume group not found on restart [resent]
Heinz J . Mauelshagen
mauelshagen at sistina.com
Wed May 22 13:25:02 UTC 2002
On Wed, May 22, 2002 at 01:58:22PM -0400, Murthy Kambhampaty wrote:
> Heinz, the "gone one" has been gone for a long while. It was a single SCSI
> disk (/dev/sda) which I added to the VG to use for snapshotting db_dir (for
> backup) and would immediately lvremove (see the SnapBach.sh script below;
> not too sophisticated, just faithfully replicates the necessary keytrokes).
As my tiny little helper scripts typically look as well ;-)
>
> However, the snapshot strategy did not work out for me (it was for backing
> up my production databases; I decided to get MySQL to hotcopy the databases,
> and then do a [xfs]dump of the filesystem containing the hotcopy). So, I did
> a vgreduce /dev/sda, but pvscan kept telling me it was still in VG "db_vol",
Well, that shouldn't have happened in case "vgreduce db_vol /dev/sda" went ok
back then.
Do you have any memory of failure messages for that one?
> so I did an lvmchange -R to see if I could "reset" the information, but that
> didn't work, so I rebooted and then pvscan only gave /dev/rd/c0d0p6 in
> "db_vol". NOTE: I was/am still learning to deal with LVM; I think I figured
> out that all I needed to do was a vgscan, which is what the reboot did; too
> much exposure to MS Windows, I guess ;(.
>
> So, the preferred course here is to "to change the metadata in order to get
> rid of the gone physical volume", and all will be well.
So there's cons vs. (temporarly) trying 1.1-rc to quorum activate db_vol
in order to retrieve the data?
Regards,
Heinz -- The LVM Guy --
>
> Thanks for your continuing assistance. Its really great that you got on top
> of this issue so quickly.
>
> I look forward to your advice on the steps necessary for changing the
> metadata,
> Murthy
>
>
> Begin script SnapBack.sh:
> #!/bin/bash
> # FN: SnapBack.sh
> # AB: Archives /home/db to a daily backup file on compa5
> # DT: 20020321
> # AU: Murthy Kambhampaty
>
> SnapDir=/dev/db_vol/db_dir
> SnapLVName=snap_db
> SnapLVPath=/dev/db_vol/snap_db
> SnapMount=/mnt/dbsnap
>
> /sbin/lvcreate -s -l 4999 -n $SnapLVName $SnapDir ; \
> mount -v -t xfs -o ro,nouuid,norecovery $SnapLVPath $SnapMount ; \
> cd $SnapMount ; \
> /opt/schily/bin/star -czl \
> f=/mnt/dbback/$(date +%A)_snap.tar . ; \
> cd / ; \
> umount -v $SnapMount ; \
> /sbin/lvremove -f $SnapLVPath
> End SnapBack.sh script.
>
> > -----Original Message-----
> > From: Heinz J . Mauelshagen [mailto:mauelshagen at sistina.com]
> > Sent: Wednesday, May 22, 2002 13:21
> > To: linux-lvm at sistina.com
> > Subject: Re: [linux-lvm] Volume group not found on restart [resent]
> >
> >
> >
> > Murthy,
> >
> > the metadata you sent to me directly shows, that 2 physical
> > volumes belong
> > to your volume group db_vol but only one can be found on
> > /dev/rd/c0d0p6.
> >
> ...
> >
> > If you can't get the physical volume back, there's hope to change the
> > metadata in order to get rid of the gone physical volume.
> > That could be possible, because logical volume "db_dir" seems
> > to be allocated
> > on /dev/rd/c0d0p6 only and "snap_db" on the gone physical volume.
> >
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm at sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer Am Sonnenhang 11
56242 Marienrachdorf
Germany
Mauelshagen at Sistina.com +49 2626 141200
FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
More information about the linux-lvm
mailing list