LVM thin volumes aren't detected and causing errors
A partition and disk imaging/cloning program
Brought to you by:
steven_shiau
Menu
▾
▴
#330 LVM thin volumes aren't detected and causing errors
Summary: Clonezilla aren't able to work with LVM partitions containing thinly provisioned LVs. It can clone underlying thin LVs with the data, but can't clone thin pool resulting a skip during cloning and an error during restoration process. Every type of backup (even dd-based) will fail, including both disk to image and partition to image.
Versions affected: most likely all. Tried stable - 2.6.2-15, alternate testing 20190821-eoan-amd64.
Steps to reproduce:
- Make sure LVM and thin provisioning tools are installed (i.e. 'apt install thin-provisioning-tools' on debian-based distros).
- Create an emtpy volume group with 'vgcreate testVG <physical-volume>.</physical-volume>
- Create a thin pool container with 'lvcreate -T -L <size> -n test-pool testVG'.</size>
- Create a thinly provisioned LV with 'lvcreate -T -V <size> -n test-thinLV testVG/test-pool'.</size>
- Possible, but not required is to create an FS and write some data on newly thin LV: 'mkfs.ext4 /dev/testVG/test-thinLV && mkdir /mnt/thin-tmp && mount /dev/testVG/test-thinLV /mnt/thin-tmp && dd if=/dev/urandom bs=1M count=128 of=/mnt/thin-tmp/test.dat && umount /dev/testVG/test-thinLV && rmdir /mnt/thin-tmp'
- Try to create an image with Clonezilla of the physical volume with those thin LVs.
Should be easy to fix. We don't need to store anything from thin pool, except for it's metadata which is already recorded during backup process (it's all in lvm.conf). Only required action is to add a handler to check if this volume are thin pool or a thin volume (i.e. member of thin pool) and record that relation in some file. During the restoration process thin pool should be recreated with the same (or scaled) size and the belonging thinly provisioned LVs should be created with '-T -V <size> <vg thin-pool="">' options.</vg></size>
Popular Proxmox VE distro uses thin pools by default on installation. This causes Clonezilla are not able to backup it at all.
I just ran into the exact same problem. I just ruined a server. Anyone know how to fix the corrupt LVM with thin storage?
You can try to manually restore it from clonezilla backup actually if the underlying thin volumes were backuped correctly (when I've tested they were).
Boot with clonezilla, try to restore your backup to restore normal (non-thin) LVs. Then check your lvm_VGNAMGE.conf from your backup. It should have all the thin volumes stored there. You have to manually create thin pools with type = "thin-pool" and create an emtpy thin LVs with type = "thin". Then use a partclone.FSTYPE -r to restore your LV content back to manully created thin LVs.
Only a theory, not tested, but that should work.
I couldn't get it done. My lvm skills are not so great. I figured it'll be easier for me to restore an older backup. Thanks anyway!
Thank you all for your feedback. We will do our best to support LVM thin volume in the future.
Steven
So far we are still having issues to make this work. For more info, please check:
https://github.com/jthornber/thin-provisioning-tools/issues/126
Steven
Hi Steven, clonezilla fails even when instructed in dd mode (-q1); Still attempts and fails to parse lvm, even when explicitly lvm access to devices is restricted via lvm filters! I had to enable lvm filters because ocs-sr ignores -q1 , yet still ignores everything and goes by lvm signatures found on disk. I just gave up and done a manual dd...
user@lunar:/home/partimag$ cat /var/log/clonezilla.log | nc termbin.com 9999
https://termbin.com/psv3
user@lunar:/home/partimag$ lvmconfig | nc termbin.com 9999
WARNING: Running as a non-root user. Functionality may be unavailable.
https://termbin.com/2h3y
please read the termbin output as soon as possible as they expire quite often.
using clonezilla-live-20230629-lunar-amd64.iso
also, why savedisk wants individual partitions? isn't savedisk's whole point to ignore partitions and just dump the entire block device?
Because file system in on a partition or LV... When dealing with file system, we have to do so.
If you use dd to process the whole disk, of course you do not care about the file system.
Steven
Clonezilla does have some issue to process LVM thin provisioning... I would say if upstream provides a better way to deal with LVM configuration saving and resotoring, it would be easier for Clonezilla to support it.
Steven
there seems to be new ideas discussed over there in that lvm issue about saving not the thin LV's but the thin pool itself, by copying the hidden pool data and pool metadata, then restoring them.
also, why can't dd mode work for savedisk? it's quite not what I'd expect from a cloning tool, to fail unconditionally just because it encountered a thin pool. it seems to want to do it the lvm way, even when you say you want dd.
If you have time, please give testing Clonezilla live >= 3.3.2-8 or 20260318-* a try:
https://clonezilla.org/downloads.php
We have improved the support for LVM thin provisioning.
Please let us know the results after you try that.
I can confirm the LVM thin provisioning problems persist in Clonezilla Live 3.3.3-15 (stable), on a Proxmox VE host with the standard layout: single disk, VG pve, thin pool pve/data holding all VM/CT disks.
What happened:
Backup of the system disk completed without obvious errors (default savedisk mode, image to external target)
After restore, the host booted, but activating pve/data failed with having all ct/vm disks available but empty, leaving all VMs/CTs inaccessible
Recovery was done via the Proxmox/LVM route (recreating the pool and restoring guests from separate backups), which unfortunately means the original Clonezilla log was lost in the process
Lesson for others: Before attempting any manual recovery, save /var/log/clonezilla/clonezilla.log from the live environment — it would be the key artifact to diagnose whether the thin pool metadata is being backed up/restored at all in 3.3.3-15.
Questions:
Should the improved thin-provisioning support (>= 3.3.2-8) cover the thin pool metadata restore on Proxmox-style pve/data layouts, or are only standalone thin LVs handled?
the only thing i can provide are logs on the proxmox system so if you assume there are any files in the cloned system (i also lost the system where i was cloning from maybe (but i think not) due to boothing with both drives Attached. Anyway - be aware!!!). But i someone has a idea i try to get some logs ... reproduction might be possible but means destroying my new system (and restore it later from new backup ... i'd prefer to avoid it)