20

Basically, I want to move / copy several logical volumes (lv) into a new volume group (vg). The new volume group reside on a new set of physical volumes. Does anyone know how to do that safely without damaging to the data inside those logical volumes??

Improve this question
3
  • Can you provide more details ? Do you know how to make new VG and LV ? Are you moving a data partition or your root partition ?
    – Panther
    Dec 28, 2011 at 17:31
  • @bodhi.zazen : Actually I was trying to move a kind of data partitions. What I meant by "kind of" was, those logical volumes are virtual machines. (i.e. those logical volumes are appeared to virtual machines as block devices). Anyway, I was able to handle the situation in my own way. The steps are given in my answer. However, you and all of you are welcome to comment on my method. If there is/are a better way(s) to do this kind of thing please be kind enough to share it. :)
    – nobody
    Dec 29, 2011 at 3:34
  • I would have first created the new PV/LV , shut down the VM, then copied the data with dd, boot the new VM and confirm it worked.
    – Panther
    Dec 29, 2011 at 4:31

7 Answers 7

Reset to default
13

vgmerge lets you merge two VGs. You can also use pvmove to move data within a VG, and vgsplit if you want to go back to multiple VGs.

Improve this answer
1
  • One note. For do it, you must have temporary device used for transfer online LV to another VG. Of course after transfer you should update /etc/fstab and other affected configuration, and plan some offline time for reboot, and eventually make some config update. If you do some action with rootfs or bootfs, you should have got some linux live distro for recovery main system.
    – Znik
    Jan 3, 2020 at 11:04
11

There is no reason to copy it to a .img file first, just do the lvcreate first, then directly copy it over:

lvcreate --snapshot --name <the-name-of-the-snapshot> --size <the size> /dev/volume-group/logical-volume
lvcreate --name <logical-volume-name> --size <size> the-new-volume-group-name
dd if=/dev/volume-group/snapshot-name of=/dev/new-volume-group/new-logical-volume
Improve this answer
2
  • 2
    This is little too brief. It does not say what exactly are the mentioned sizes - for example <the size> can be very small, as it is only for snapshot differencies.
    – gorn
    Apr 27, 2016 at 2:05
  • 1
    @gorn a valid point, but he was replying to nobody's answer below, which was first at the time. Read that for additional context.
    – Tobias J
    Oct 21, 2016 at 18:29
7

Okay, I was able to handle the situation in my own way. Here are the steps I took:

1) Take a snapshot of the targeting logical volume.

lvcreate --snapshot --name <the-name-of-the-snapshot> --size <the size> /dev/volume-group/logical-volume

Note : Size of the snapshot can be as large as or as small as you wish. What matters is having enough space to capture changes during snapshot period.

2) Create an image copy of the snapshot content using dd

dd if=/dev/volume-group/snapshot-name of=/tmp/backup.img

3) Create a new logical volume of enough size in the targeting (new) volume group.

lvcreate --name <logical-volume-name> --size <size> the-new-volume-group-name

4) Write data to the new logical volume from the image backup using dd

dd if=/tmp/backup.img of=/dev/new-volume-group/new-logical-volume

5) delete the snapshot and image backup using lvremove and rm respectively.

That's all folks... Hope this helps to someone :)

Improve this answer
2
  • If someone has better option / method, let me know as well :-)
    – nobody
    Dec 29, 2011 at 5:25
  • ising backup.img for temporarly store backup is complete unneeded. you can directly dd from source snapshot, to destination LV with not mounted state.
    – Znik
    Jan 3, 2020 at 11:07
5

I will offer my own:

umount /somedir/

lvdisplay /dev/vgsource/lv0 --units b

lvcreate -L 12345b -n lv0 vgtarget

dd if=/dev/vgsource/lv0 of=/dev/vgtarget/lv0 bs=1024K conv=noerror,sync status=progress

mount /dev/vgtarget/lv0 /somedir/

if everything is good, remove the source

lvremove vgsource/lv0
Improve this answer
1
  • what if source volume is very big and service or system shouldn't be stopped?
    – Znik
    Jan 3, 2020 at 11:17
4

As of the LVM in Debian stretch (9.0), namely 2.02.168-2, it's possible to do a copy of a logical volume across volume groups using a combination of vgmerge, lvconvert, and vgsplit. Since a move is a combination of a copy and a delete, this will also work for a move.

Alternatively, you can use pvmove to just move the volume.

A complete self-contained example session using loop devices and lvconvert follows.

Summary: we create volume group vg1 with logical volume lv1, and vg2 with lv2, and make a copy of lv1 in vg2.

Create files.

truncate pv1 --size 100MB
truncate pv2 --size 100MB

Set up loop devices on files.

losetup /dev/loop1 pv1
losetup /dev/loop2 pv2

Create physical volumes on loop devices (initialize loop devices for use by LVM).

pvcreate /dev/loop1 /dev/loop2

Create volume groups vg1 and vg2 on /dev/loop1 and /dev/loop2 respectively.

vgcreate vg1 /dev/loop1
vgcreate vg2 /dev/loop2

Create logical volumes lv1 and lv2 on vg1 and vg2 respectively.

lvcreate -L 10M -n lv1 vg1
lvcreate -L 10M -n lv2 vg2

Create ext4 filesystems on lv1 and lv2.

mkfs.ext4 -j /dev/vg1/lv1
mkfs.ext4 -j /dev/vg2/lv2

Optionally, write something on lv1 so you can later check the copy was correctly created. Make vg1 inactive.

vgchange -a n vg1

Run merge command in test mode. This merges lv1 into lv2.

vgmerge -A y -l -t -v <<destination-vg>> <<source-vg>>
vgmerge -A y -l -t -v vg2 vg1

And then for real.

vgmerge -A y -l -v vg2 vg1

Then create a RAID 1 mirror pair from lv1 using lvconvert. The <> argument tells lvconvert to make the mirror copy lv1_copy on /dev/loop2.

lvconvert --type raid1 --mirrors 1 <<source-lv>> <<dest-pv>>
lvconvert --type raid1 --mirrors 1 /dev/vg2/lv1 /dev/loop2

Then split the mirror. The new LV is now lv1_copy.

lvconvert --splitmirrors 1 --name <<source-lv-copy>> <<source-lv>>
lvconvert --splitmirrors 1 --name lv1_copy /dev/vg2/lv1

Make vg2 inactive.

vgchange -a n vg2

Then (testing mode)

vgsplit -t -v <<source-vg>> <<destination-vg>> <<moved-to-pv>>
vgsplit -t -v /dev/vg2 /dev/vg1 /dev/loop1

For real

vgsplit -v /dev/vg2 /dev/vg1 /dev/loop1

Resulting output:

lvs
[...]
lv1        vg1       -wi-a-----  12.00m
lv1_copy   vg2       -wi-a-----  12.00m
lv2        vg2       -wi-a-----  12.00m

NOTES:

1) Most of these commands will need to be run as root.

2) If there is any duplication of the names of the logical volumes in the two volume groups, vgmerge will refuse to proceed.

3) On merge:

Logical volumes in `vg1` must be inactive

And on split:

Logical volume `vg2/lv1` must be inactive.
Improve this answer
2
  • 1
    it is just pointless. You have to unmount filesystems ,deactivate volumes etc. You may just unmount dir and copy data as well.
    – user189142
    Sep 21, 2017 at 10:31
  • first, as user189142 said, it is pointless. second, it is applied only with situation when we can stop services using moved volume. this is problem with services running 24/7, and volume is very big with data counted with terabytes. This cause, this procedure needs very long service time. This cause, much easier is simply creating new volume, rsync online, then with short time rsync offline for update, remount and back system to online state. Of course, the very good idea is wipe out unneeded data from source volume. maybe temporarly move it to some temporary place.
    – Znik
    Jan 3, 2020 at 11:14
3

The 4 answers so far all miss that the exact size of the volume often is not known. lvdisplay only shows values rounded to 2 decimal places and man lvdisplay only points to other commands for available options. The following selects MiB, which is sufficiently accurate with the default LVM block size of 4 MiB:

lvdisplay --units m

MiB is also the default unit for --size of lvcreate. If in doubt, double check the correct size with lvdisplay after creating the target volume. Then go ahead as in the other answers to make a copy. Furthermore, I'd recommend to verify the copy, for example with cmp.

Here why a snapshot is used and what it protects and doesn't protect:

  • The snapshot is made so that all data is copied as it was at the time the snapshot was created. Activities on the source volume during the copy process will not be reflected in the copy.

  • The snapshot also protects the source volume from human errors in the dd command line. If you accidentally write to the snapshot, only the snapshot's data will be damaged and you can simply remove the snapshot and start over.

  • The target volume is not protected during the copy processes. If another admin (or an automatic process such as the os-prober of dracut) mounts the incomplete volume, the mount may screw up things. (Even a read-only mount may still write journal entries to the volume.)

Improve this answer
0

If you need to copy a logical volume from VG A to another VG B, I found a interesting variant using partclone. The snapshot then copy with dd is a good method but might be slow if your file-systems are not full. This solution is very fast because it copy only the used blocks.

  1. First create a snapshot of the source LV
lvcreate --snapshot --size 1G /dev/sourcevg/lv --name lv-backup

the --size here is how much write can occur before the snapshot will be disabled

  1. Create the destination LV in the destination VG
lvcreate --size <new_lv_size> /dev/destvg --name newlv

new_lv_size must be at least the size of the source LV

  1. Copy the file-system from source lv backup to destination LV
partclone.<fs_type> --dev-to-dev --source /dev/sourcevg/lv-backup --output /dev/destvg/newlv

fs_type can be ext4, fat32, btrfs, xfs, ... any FS supported by partclone

  1. Delete the snapshot
lvremove /dev/sourcevg/lv-backup
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.