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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox