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.

_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

Reply via email to