[linux-lvm] creating DD copies of disks

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

Re: [linux-lvm] creating DD copies of disks

[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

Re: [linux-lvm] creating DD copies of disks

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

Re: [linux-lvm] creating DD copies of disks

[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

Re: [linux-lvm] creating DD copies of disks

[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

Re: [linux-lvm] creating DD copies of disks

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

Re: [linux-lvm] creating DD copies of disks

[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 <list@xenhideout.nl>
To:             	linux-lvm@redhat.com
Subject:        	Re: [linux-lvm] creating DD copies of disks
Send reply to:  	LVM general discussion and development 
<linux-lvm@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-lvm@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:mikes@kuentos.guam.net                            
  mailto:msetzerii@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)

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

Re: [linux-lvm] creating DD copies of disks

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

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

Re: [linux-lvm] creating DD copies of disks

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