Hi,
This is the steps that I did.
- the COW data exists on /dev/loop1, including space for the PV header +
metadata
I created a fakevg template file from vgcfgbackup /tmp/fakevg.bkp
( the content of this file I created fake uuid etc... )
I craete a fake uuid for the PV
# pvcreate -ff -u fake-uidx-nrxx-xxxx --restorefile /tmp/fakevg.bkp
And created rhe metadata from the backup
# vgcfgrestore -f /tmp/fakevg.bkp fakevg
I can now see the lvsnap in fakevg
Perhaps the restore can be done directly to the destination vg? not sure...
Anyhow, I than used the vgsplit to move the fakevg data to the
destination vg
# vgsplit fakevg destvg /dev/loop1
I know have the lvsnap volume in the correct volume group
From here, I connected the lvsnap to a lv destination using
# lvconvert -Zn -s destvg/lvsnap destvg/destlv
I know have a snapshot connected to the origin destlv
From here, I can either mount the snapshot and start using it, or
revert to the snapshot
# lvchange -a n destvg/destlv
# lvconvert --merge -b destvg/lvsnap
# lvchange -a y destvg/destlv
Now to my questions...
is there any DBUS api that can perform the vgcfgrestore operations that
I can use through C?
or another ways to recreate the metadata?
I have to now use two steps: pvcreate + vgcfgrestore, where I just need
to actually restore just the metadata (only vgcfgrestore)?
If I run vgcfgrestore without pvcreate, than vgcfgrestore will not find
the pvid, and cant be executed with a parameter like:
# vgcfgrestore -f vgXX.bkp /dev/nbd
Instead it has to be used with the parameter vgXX pointing out the
volume group...
I can live with vgcfgrestore + pvcreate, but would prefer to use the
libblockdev (DBUS) or another api from C directly.
What options do I have?
Thanks for an excellent help
God Bless
Tomas
Den 2020-09-07 kl. 19:50, skrev Zdenek Kabelac:
Dne 07. 09. 20 v 19:37 Tomas Dalebjörk napsal(a):
thanks
ok
vgsplit/merge instead
and after that lvconvert-s
yes, I am aware of the issues with corruption
but if the cow device has all data, than no corruption will happen,
right?
if COW has a copy of all blocks
than a lvconvert —merge, or mount of the snapshot volume will be
without issues
If the 'COW' has all the data - why do you need then snapshot ?
Why not travel whole LV instead of snapshot ?
Also - nowdays this old (so called 'thick') snapshot is really slow
compared with thin-provisioning - might be good if you check what kind
of features
you can gain/loose if you would have switched to thin-pool
(clearly whole thin-pool (both data & metadata) would need to travel
between your VGs.)
Regards
Zdenek
_______________________________________________
linux-lvm mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
