Re: creating DD copies of disks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

_______________________________________________
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/



[Index of Archives]     [Gluster Users]     [Kernel Development]     [Linux Clusters]     [Device Mapper]     [Security]     [Bugtraq]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]

  Powered by Linux