From: "Heinz J . Mauelshagen" <mauelshagen@sistina.com>
To: linux-lvm@sistina.com
Subject: Re: [linux-lvm] Volume group not found on restart [resent]
Date: Wed May 22 13:25:02 2002 [thread overview]
Message-ID: <20020522202056.A10845@sistina.com> (raw)
In-Reply-To: <E631530D51ABD411B823009027855C5B0278BE@THOR>; from Murthy.Kambhampaty@goeci.com on Wed, May 22, 2002 at 01:58:22PM -0400
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@sistina.com]
> > Sent: Wednesday, May 22, 2002 13:21
> > To: linux-lvm@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@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@Sistina.com +49 2626 141200
FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
next prev parent reply other threads:[~2002-05-22 13:25 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-22 12:59 [linux-lvm] Volume group not found on restart [resent] Murthy Kambhampaty
2002-05-22 13:25 ` Heinz J . Mauelshagen [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-05-23 14:10 Murthy Kambhampaty
2002-05-24 3:37 ` Heinz J . Mauelshagen
2002-05-22 14:05 Murthy Kambhampaty
2002-05-23 12:15 ` Heinz J . Mauelshagen
[not found] <E631530D51ABD411B823009027855C5B0278B1@THOR>
2002-05-22 3:48 ` Heinz J . Mauelshagen
2002-05-22 12:24 ` Heinz J . Mauelshagen
2002-05-17 9:24 Murthy Kambhampaty
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=20020522202056.A10845@sistina.com \
--to=mauelshagen@sistina.com \
--cc=linux-lvm@sistina.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.