From: Xen <list@xenhideout.nl>
To: Linux lvm <linux-lvm@redhat.com>
Subject: [linux-lvm] creating DD copies of disks
Date: Sat, 17 Sep 2016 09:29:16 +0200 [thread overview]
Message-ID: <7e54ddf6638609d4e521287b51964ebd@dds.nl> (raw)
I want to ask again:
What is the proper procedure when duplicating a disk with DD?
- after duplication you cannot update a PV with pvchange -u because it
will supersede your duplicate with the original and not do anything
So to do that you need to boot off a different system, deactivate loaded
vgs (if any) and then pvchange -u the duplicate PV.
- my experience indicates that pvchange -ay on a PV that contains a
duplicate VG, even if it has a different UUID, but with an identical
name, creates problems.
I mean that anytime you load a VG with the same name you get issues. VG
names are often standardized between installs, so that Ubuntu might have
"ubuntu-vg" as the name and kubuntu might have "kubuntu-vg" as the name.
So if you then load two of those disks in the same system, you instantly
have issues.
If the system were to auto- or temporary-rename an offending 2nd VG it
wouldn't be so bad. But usually you have to vgrename rename your current
VG in advance of loading a second disk.
Which isn't exactly as intended, because now you are changing your local
name to make room for a second system, when it should really be the
other way around.
In the end I feel I have to do:
pvchange -u
vgchange -u
vgrename
To get something that will at least not bug me when both systems are
loaded at the same time.
This then renders it impossible to use it as a backup because any other
disk referencing the PV will not find it because the UUID has changed.
Now you would first have to reverse these operations (particularly the
vgrename and pvchange -u) towards the data of the first disk (the
original) to be able to use the device again.
All of that is not very resilient. Now both PV UUIDs and VG names have
to be unique.
Particularly I wonder how easy it is to point an existing VG to a disk
that has a new (duplicate) PV and tell it: use that one from now on.
I mean: how can I add a disk that has a duplicate PV with a different
UUID and add it to the VG in such a way that it replaces the references
that VG has for the old PV?
But also: what ought you to do if creating a mirror copy? (duplicate
copy).
next reply other threads:[~2016-09-17 7:29 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-17 7:29 Xen [this message]
2016-09-17 13:49 ` [linux-lvm] creating DD copies of disks Lars Ellenberg
2016-09-17 14:40 ` Xen
2016-09-17 18:02 ` Lars Ellenberg
2016-09-20 8:04 ` Zdenek Kabelac
[not found] <368387847.156920.1474117496841.ref@mail.yahoo.com>
2016-09-17 13:04 ` matthew patton
2016-09-17 14:16 ` Xen
2016-09-17 14:53 ` Xen
2016-09-17 15:18 ` Michael D. Setzer II
2016-09-17 15:40 ` Xen
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=7e54ddf6638609d4e521287b51964ebd@dds.nl \
--to=list@xenhideout.nl \
--cc=linux-lvm@redhat.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.