[linux-lvm] creating DD copies of disks
list at xenhideout.nl
Sat Sep 17 14:40:36 UTC 2016
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
>> 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
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.
More information about the linux-lvm