The recovery options are more limited with thin provisioning. Sort out what existing functionality needs to be restricted or have warnings and see what backup/recovery options can still be offered.
For 6.4 we provide 'temporary' solution for users. We will support restore of metadata with thin volumes with --force option. The complex logic for restore is going to be handled by another new tool. --force option is introduced by this upstream patch: https://www.redhat.com/archives/lvm-devel/2012-November/msg00065.html
This limited solution is allowing a thin pool user to fix broken pool by himself - the tool does not make any internal consistency check - but with combination of thin_restore, user should be able to fix thin pool (i.e. put in proper transaction_id to match the one found in metadata). The --force is needed to emphasize the tool is not doing any checks. Without the force the tool refuses to read any VG metadata with thin pool data in them. So i.e. even if you would want to restore metadata because of the operation on plain linear LV - if the VG would also have thin pool - user would not be able to use vgcfgrestore. With --force we add the option to proceed in such case easily. We will provide lvconvert --repair functionality which will slowly gain more intelligence so more things could be fixed by the tools automatically.
Let's add more of validation and fixes. From my 'support' experience - these 2 features would greatly extend usability of 'lvconvert --repair' for thin-pool 1. Allow to update lvm2 metadata to match 'kernel' version. 2. Cleanup unset messages for thin-pool Let's targets for this 2 - possibly more will come....
closing due to better bug (and comment 16)