[linux-lvm] creating DD copies of disks

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