[linux-lvm] creating DD copies of disks

[Xen]

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).

[matthew patton]

> What is the proper procedure when duplicating a disk with DD?

If you're literally duplicating the entire disk, what on earth are you doing keeping it in the same system? OF COURSE you remove it from the origin box if you expect to do anything with it. And I presume there are no active filesystems or frankly writable LVM components on the source disk while the DD is running?

Most times it's only the filesystems that contain interesting data an so a DD of the filesystem is understandable even though there are other tools like RSYNC which are more logical.

If you're trying to make a forensic copy, please delegate the task to professionals, who know what they are doing.

[Xen]

matthew patton schreef op 17-09-2016 15:04:
>> What is the proper procedure when duplicating a disk with DD?
>
> If you're literally duplicating the entire disk, what on earth are you
> doing keeping it in the same system?

That's very simple, I'm surprised you wouldn't see it.

> OF COURSE you remove it from the
> origin box if you expect to do anything with it.

Why would you? That's like making a photo-copy of something and then
moving to another house before you can read it.

If anything, it's only technical limitations that would mandate such a
thing. This also doesn't answer the question of what to do if you have
VG with identical names.

> And I presume there
> are no active filesystems or frankly writable LVM components on the
> source disk while the DD is running?

Nope. All VGS had been deactivated (was running from a bootable stick).


> Most times it's only the filesystems that contain interesting data an
> so a DD of the filesystem is understandable even though there are
> other tools like RSYNC which are more logical.

Trouble is making a backup of a complex setup is also complex if you
don't have the required tools for it and even "clonezilla" cannot really
handle LVM that well. So you're down to manually writing scripts to do
all of the steps that you need to do to back up the required data (e.g.
LVM metadata, and such) and then the steps to recreate it when you
restore a backup (if any).

So in this case I was just making a backup of a disk because I might be
needing to send the origin disk out for repair, so to speak. The disk
contains various partitions and LVM structures. A clonezilla backup is
possible, but cannot handle encryption. But because the new disk is
meant to replace the old one (for a time) I need a literal copy anyway.
Now of course I could clone the non-LVM partitions and then recreate
volume groups etc. with different names, but this is arduous.

In that case I would have unique UUIDs but would still need to change my
new volume group names so the systems can coexist while the copy is
running.

At this point I'm not even sure.... well.

Let's just say I need to ensure the operation of this disk in this
system completely prior to dumping the old one. There are only two ways:
disconnect the source disk (and try to boot from the new system, etc.)
or run from usb stick and disconnect the source disk, in that case. But
if issues arise, I may need the source disk as well. Why would there not
be an option to have it loaded at the same time? They are separate
disks, and should ideally not directly conflict. In the days prior to
UUID, this never happened; there were never any conflicts in that sense
(unless you use filesystem labels and partition labels of course).

So I first want to settle into a peaceful coexistence because that is
the most potent place to move forward from, I'm sure you understand.
First cover the basics, then move on.

One answer.... well.

In any case it is clear that after changing the UUID of the PV and VG
and changing the VG name, the duplicate disk can serve just fine for the
activation of certain things, because LVM doesn't care what your VG is
called, it will just find your LV by its UUID, if that makes sense.

So the duplicate LVS still have identical UUIDs and hence still perform
in the old way (and cannot really coexist now).

However it seems not possible to change the UUID of a LV.

https://www.redhat.com/archives/rhl-list/2008-March/msg00329.html

Not answered to satisfaction. Why would you need to use two different
systems to copy data between two disks? That seems hardly possible.

I have now two VGS with different UUIDs:

VG UUID jrDQRC-6tlI-n1xK-O7nh-xVAt-Y5SL-Ou8X7b
VG UUID KyWokE-ddUN-8GXO-HgWA-5bqU-9HN2-57Qyho

But when I allow the 2nd one (the new one) to be activated, and activate
something else as well, its LVs will be used just fine as PV for
something else, based on UUID and nothing else.


Indeed, blkid will show them as having identical UUIDs.

Now I had forgot to run pvchange -u on those LVs, so I guess Alistair
was right in that thread. But the pvchange -u also instantly updated the
VGS that referenced it; which is not so bad, but now the system will run
with the new disk, and not the old disk.

But that means part of the "migration" is at least complete from this
point of view. So thank you.

Now that Linux has no issues whatsoever I will have to see what Windows
is going to do.

It's nice to know that when you change the UUID of a LV that is used as
PV for something else, that something else is updated automatically.
That was part of my question: how do I inform the "user" of the changed
PVS (UUIDS)?

So what I have now is basically a duplicate disk but all the UUIDs are
different (at least for the LVM).

But generally I do not mount with UUID so for the partitions it is not
really an issue now.

The backup was also made for safety at this point.

I just won't be able to use the old system until I change it back. Time
to test, isn't it.

[Xen]

Xen schreef op 17-09-2016 16:16:

> I just won't be able to use the old system until I change it back.
> Time to test, isn't it.

Indeed both Linux and Windows have no issues with the new disk, I think.

I was making a backup onto a bigger-sized disk, but neither Windows nor
Linux have an issue with it. They just see the old partition table of
the old disk and are fine with that.

Now I only need to know if the Linux system will run with the new disk,
but I'm sure there won't be issues there now. The system is not actually
*on* that disk.

Call it a data disk for an SSD system.

So perhaps you can see why I would want to have the two disks loaded at
the same time:

- if they work, I can copy data even after the DD (perhaps, to make some
rsync copy as you indicate) but now I already have all the required
structures (partition tables...) without any work.

- I wasn't actually yet done with the old disk. This was also just
research. Better make a backup first before you finalize things. I want
to do more work on the "old" system before I finalize things. But having
a backup sitting there that I can use is a plus. Having to not be able
to use both disks at the same time is a huge detriment. It is also not
that hard now to change the system back but I still don't know how I can
manually change the UUIDs that a VG/LV references. It is a huge plus if
I can just exchange one PV with another at will.

[Michael D. Setzer II]

I've been the maintainer of the G4L disk imaging project since 2004, and
many of its options are using dd with compression to make disk/partition
images or clone disks.

A couple of issues. if you make an image or clone of the disk, you probable
will not have a problem since it will copy the blkid info from the old drive, so it
will match as part of boot process. The big problem is if the new disk is going
into a machine with a controller that is not part of you initrd. The disk will be
identical, but since the contoller isn't included it will not be able to boot.

Recently, had a motherboard in a system go bad. Moved disk to another
machine, and default kernel wouldn't boot because of different on board
controller. Was able to boot from the older rescue kernel, and then go thru
the process of rebuilding the initrd for the latest kernel. Then that one booted
fine.

Had a similar issue many years ago, when I imaged an IDE hard disk to a
new sata disk.

With windows systems, there seem to be more issues. On the same machine
it works fine, but moving to systems that are just a little different sometimes
results in various messages.

Good Luck.


On 17 Sep 2016 at 16:53, Xen wrote:

Date sent: Sat, 17 Sep 2016 16:53:14 +0200
From: Xen <***@xenhideout.nl>
To: linux-***@redhat.com
Subject: Re: [linux-lvm] creating DD copies of disks
Send reply to: LVM general discussion and development
<linux-***@redhat.com>

> Xen schreef op 17-09-2016 16:16:
>
> > I just won't be able to use the old system until I change it back.
> > Time to test, isn't it.
>
> Indeed both Linux and Windows have no issues with the new disk, I think.
>
> I was making a backup onto a bigger-sized disk, but neither Windows nor
> Linux have an issue with it. They just see the old partition table of
> the old disk and are fine with that.
>
> Now I only need to know if the Linux system will run with the new disk,
> but I'm sure there won't be issues there now. The system is not actually
> *on* that disk.
>
> Call it a data disk for an SSD system.
>
> So perhaps you can see why I would want to have the two disks loaded at
> the same time:
>
> - if they work, I can copy data even after the DD (perhaps, to make some
> rsync copy as you indicate) but now I already have all the required
> structures (partition tables...) without any work.
>
> - I wasn't actually yet done with the old disk. This was also just
> research. Better make a backup first before you finalize things. I want
> to do more work on the "old" system before I finalize things. But having
> a backup sitting there that I can use is a plus. Having to not be able
> to use both disks at the same time is a huge detriment. It is also not
> that hard now to change the system back but I still don't know how I can
> manually change the UUIDs that a VG/LV references. It is a huge plus if
> I can just exchange one PV with another at will.
>
>
>
>
> _______________________________________________
> linux-lvm mailing list
> linux-***@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/


+----------------------------------------------------------+
Michael D. Setzer II - Computer Science Instructor
Guam Community College Computer Center
mailto:***@kuentos.guam.net
mailto:***@gmail.com
Guam - Where America's Day Begins
G4L Disk Imaging Project maintainer
http://sourceforge.net/projects/g4l/
+----------------------------------------------------------+

http://setiathome.berkeley.edu (Original)
Number of Seti Units Returned: 19,471
Processing time: 32 years, 290 days, 12 hours, 58 minutes
(Total Hours: 287,489)

***@HOME CREDITS
ABC 16613838.513356 | EINSTEIN 113011037.288695
ROSETTA 48420184.415104 | SETI 91961748.223136

[Xen]

Michael D. Setzer II schreef op 17-09-2016 17:18:

> With windows systems, there seem to be more issues. On the same machine
> it works fine, but moving to systems that are just a little different
> sometimes
> results in various messages.

Windows 10 has less issues than before. You can move a system from a
"regular" disk to a "firmware raid" disk (same disk with a little bit of
firmware data at the end, and run from a different controller) and if
your raid drivers are already installed, it will boot without issue
whatsoever.

Anyway, thanks for your response.

[Lars Ellenberg]

On Sat, Sep 17, 2016 at 09:29:16AM +0200, Xen wrote:
> I want to ask again:
>
> What is the proper procedure when duplicating a disk with DD?

depends on what you define as "proper",
what the desired outcome is supposed to look like.

What exactly are you trying to do?

If you intend to "clone" PVs of some LVM2 VG,
and want to be able to activate that on the same system
without first deactivating the "original",
I suggest:

1) create consistent snapshot(s) or clone(s) of all PVs
2) import them with "vgimportclone",
which is a shell script usually in /sbin/vgimportclone,
that will do all the neccessary magic for you,
creating new "uuid"s and renaming the vg(s).

> - 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.

You don't say...

--
: Lars Ellenberg
: LINBIT | Keeping the Digital World Running
: DRBD -- Heartbeat -- Corosync -- Pacemaker
: R&D, Integration, Ops, Consulting, Support

DRBD® and LINBIT® are registered trademarks of LINBIT

[Xen]

Lars Ellenberg schreef op 17-09-2016 15:49:
> On Sat, Sep 17, 2016 at 09:29:16AM +0200, Xen wrote:
>> I want to ask again:
>>
>> What is the proper procedure when duplicating a disk with DD?
>
> depends on what you define as "proper",
> what the desired outcome is supposed to look like.
>
> What exactly are you trying to do?
>
> If you intend to "clone" PVs of some LVM2 VG,
> and want to be able to activate that on the same system
> without first deactivating the "original",
> I suggest:
>
> 1) create consistent snapshot(s) or clone(s) of all PVs
> 2) import them with "vgimportclone",
> which is a shell script usually in /sbin/vgimportclone,
> that will do all the neccessary magic for you,
> creating new "uuid"s and renaming the vg(s).

Right so that would mean first duplicating partition tables etc.

I will check that out some day. At this point it is already done,
mostly. I didn't yet know you could do that, or what a "clone" would be,
so thank you.


>> - 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.
>
> You don't say...

I do say but this is very common and you can run into it without
realizing, e.g. as you open some loopback image of some other system and
you hadn't realized it would contain an identically named VG as your own
system.

The issue is not that the problem happens, the issue is that you can't
recover from it.

After both VGs are activated, in my experience, you are screwed. You may
not be able to rename the 2nd PV, or even the first. I mean the VG
sitting in that PV.

Sometimes it means having to reboot the system and then doing it again
while renaming your own VG prior to loading the alien one.

This "you need foresight" situation is not very good.

Perhaps you can deactivate the new VG and close the PV and clear it from
the cache; I'm not sure, back then my "skill" was not as great.

The problem really is that LVM will activate a second VG with the same
name *just fine* without renaming it internally or even in display.

However, once it is activated, you are at a loss. So it will happily,
without you being able to know about it in advance, create a difficult
to reverse situation for you.

What if you *are* doing forensics (or recovery) as the Matthew person
indicated? Are you now to give your own VGS completely unique names?
Just so you can prevent any conflicts? Not a good situation.

LVM should really auto-rename conflicting VGS that get loaded after
activation of the original ones, however it is hard to pick which one
that should be, perhaps.

At least, maybe it should bolt before activating a duplicate and then
require manual intervention.

Or, just make it easier to recover from the situation. It is just
extremely common if you ever open an image of another disk (particularly
if it's your own) or if you are doing anything with default "ubuntu-vg"
or "kubuntu-vg" systems, in that sense.

I had a habit of calling my main VGs "Linux". Not any longer.

I now try to specify the system they are from, no matter how ugly.

Regards.

[Lars Ellenberg]

On Sat, Sep 17, 2016 at 04:40:36PM +0200, Xen wrote:
> Lars Ellenberg schreef op 17-09-2016 15:49:
> >On Sat, Sep 17, 2016 at 09:29:16AM +0200, Xen wrote:
> >>I want to ask again:
> >>
> >>What is the proper procedure when duplicating a disk with DD?
> >
> >depends on what you define as "proper",
> >what the desired outcome is supposed to look like.
> >
> >What exactly are you trying to do?
> >
> >If you intend to "clone" PVs of some LVM2 VG,
> >and want to be able to activate that on the same system
> >without first deactivating the "original",
> >I suggest:
> >
> >1) create consistent snapshot(s) or clone(s) of all PVs
> >2) import them with "vgimportclone",
> >which is a shell script usually in /sbin/vgimportclone,
> >that will do all the neccessary magic for you,
> >creating new "uuid"s and renaming the vg(s).
>
> Right so that would mean first duplicating partition tables etc.
>
> I will check that out some day. At this point it is already done, mostly. I
> didn't yet know you could do that, or what a "clone" would be, so thank you.

No. You check that out *now*.
It does not matter how you create your "duplicates" "clones" "snapshots"
whatever you name them. If you want, use dd. No one really cares.
What matters is that they are consistent.

Then, if you want to attach them, both original and "duplicate",
you need to change uuids of PV and VG, and the VG name.

And vgimportclone is a script that does all necessary steps for you.

So no, you don't have to write scripts,
or figure out the necessary steps.

Someone else did that for you already.
Just use it.

--
: Lars Ellenberg
: LINBIT | Keeping the Digital World Running
: DRBD -- Heartbeat -- Corosync -- Pacemaker
: R&D, Integration, Ops, Consulting, Support

DRBD® and LINBIT® are registered trademarks of LINBIT

[Zdenek Kabelac]

Dne 17.9.2016 v 20:02 Lars Ellenberg napsal(a):
> On Sat, Sep 17, 2016 at 04:40:36PM +0200, Xen wrote:
>> Lars Ellenberg schreef op 17-09-2016 15:49:
>>> On Sat, Sep 17, 2016 at 09:29:16AM +0200, Xen wrote:
>>>> I want to ask again:
>>>>
>>>> What is the proper procedure when duplicating a disk with DD?
>>>
>>> depends on what you define as "proper",
>>> what the desired outcome is supposed to look like.
>>>
>>> What exactly are you trying to do?
>>>
>>> If you intend to "clone" PVs of some LVM2 VG,
>>> and want to be able to activate that on the same system
>>> without first deactivating the "original",
>>> I suggest:
>>>
>>> 1) create consistent snapshot(s) or clone(s) of all PVs
>>> 2) import them with "vgimportclone",
>>> which is a shell script usually in /sbin/vgimportclone,
>>> that will do all the neccessary magic for you,
>>> creating new "uuid"s and renaming the vg(s).
>>
>> Right so that would mean first duplicating partition tables etc.
>>
>> I will check that out some day. At this point it is already done, mostly. I
>> didn't yet know you could do that, or what a "clone" would be, so thank you.
>
> No. You check that out *now*.
> It does not matter how you create your "duplicates" "clones" "snapshots"
> whatever you name them. If you want, use dd. No one really cares.
> What matters is that they are consistent.
>
> Then, if you want to attach them, both original and "duplicate",
> you need to change uuids of PV and VG, and the VG name.
>
> And vgimportclone is a script that does all necessary steps for you.
>
> So no, you don't have to write scripts,
> or figure out the necessary steps.
>
> Someone else did that for you already.
> Just use it.

Hi

It might be worth to mention here - lvm2 is your LEAST problem when you have
duplicate device in your system.

Udevd nor systemd can cope with those device AT ALL.
(you will actually hardly find tool which can handle them).

So once a duplicated identifier appears in your system - all related symlinks
in /dev/by* or related attached systemd services becomes just a random
unpredictable 'garbage'.

In general user-space tools are unprepared to deal with 'identical' devices.
So IMHO lvm2 is still 'lighting years' ahead here.

You could prepare device filters to actually make your 'duplicate' device
invisible to lvm2 (as I always HIGHLY recommend to use 'white-list' filter
and let lvm2 process only 'expected' device).
Recent version of lvm2 also do try to 'smartly' guess which one of duplicated
device is actually in use to further increase protection of a user...

However lvmetad is yet not fully equipped for this - but at least it will
automatically turn itself off now...

Regards

Zdenek