The basic problem is to avoid having to use your backups. If lv_home
is really "almost empty",
- you could shrink that (resize the filesystem, then shrink the logical volume), and
- use the freed-up space for a temporary volume to copy
lv_home
to.
- Then, the existing
lv_home
is empty, and you can demolish it, extend lv_root
as needed, and
- finally (if
lv_home
is really that small, initially), move the temporary volume's contents back into the part of the empty space that you don't need for lv_root
, and combine that with the temporary space.
The suggested ordering assumes that the underlying disk partitions are in the same order, of course. LVM is not suited to shifting partitions up and down (as some offline disk partitioning tools may do).
Now - the OP's question did not mention whether the underlying filesystem(s) all reside on one physical disk, and whether their disk partitions are in the same order. If they all reside on one physical disk, the question comes up whether this is partitioned with MBR (a maximum of four physical partitions) or GPT (128) -- see for example What's the difference between MBR and GPT? . In the former case, OP may have to create an extended partition as a basis for the resized lv_home
partition.
LVM is essentially three layers: physical, volumes and logical. To keep things tidy, it's nice to have the physical disks adjacent. But LVM does not require that. One could shrink lv_home
(and its filesystem and physical partition) in one step, and then create a new physical partition in the space on the end, adding that partition to the volume group corresponding to lv_root
and then running resize2fs
to extend the filesystem. Resizing up has a lot of existing practice; going down far less so -- until recently the documentation had caveats explaining that you could trash your filesystem with the tool.
These may be helpful: