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??
-
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 ?– PantherDec 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. :)– nobodyDec 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.– PantherDec 29, 2011 at 4:31
7 Answers
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.
-
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.– ZnikJan 3, 2020 at 11:04
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
-
2This 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.– gornApr 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 JOct 21, 2016 at 18:29
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 :)
-
-
ising backup.img for temporarly store backup is complete unneeded. you can directly dd from source snapshot, to destination LV with not mounted state.– ZnikJan 3, 2020 at 11:07
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
-
what if source volume is very big and service or system shouldn't be stopped?– ZnikJan 3, 2020 at 11:17
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.
-
1it is just pointless. You have to unmount filesystems ,deactivate volumes etc. You may just unmount dir and copy data as well. 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.– ZnikJan 3, 2020 at 11:14
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.)
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.
- 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
- 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
- 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
- Delete the snapshot
lvremove /dev/sourcevg/lv-backup