[linux-lvm] Snapshot behavior on classic LVM vs ThinLVM

Gionatan Danti g.danti at assyoma.it
Thu Apr 6 14:31:31 UTC 2017


Hi all,
I'm seeking some advice for a new virtualization system (KVM) on top of 
LVM. The goal is to take agentless backups via LVM snapshots.

In short: what you suggest to snapshot a quite big (8+ TB) volume? 
Classic LVM (with old snapshot behavior) or thinlvm (and its new 
snapshot method)?

Long story:
In the past, I used classical, preallocated logical volumes directly 
exported as virtual disks. In this case, I snapshot the single LV I want 
to backup and, using dd/ddrescue, I copy it.

Problem is this solution prevents any use of thin allocation or sparse 
files, so I tried to replace it with something filesystem-based. Lately 
I used another approach, configuring a single thinly provisioned LV 
(with no zeroing) + XFS + raw or qcow2 virtual machine images. To make 
backups, I snapshotted the entire thin LV and, after mounting it, I 
copied the required files.

So far this second solution worked quite well. However, before using it 
in more and more installations, I wonder if it is the correct approach 
or if something better, especially from a stability standpoint, is possible.

Gived that I would like to use XFS, and that I need snapshots at the 
block level, two possibilities came to mind:

1) continue to use thinlvm + thin snapshots + XFS. What do you think 
about a 8+ TB thin pool/volume with relatively small (64/128KB) chunks? 
Would you be comfortable using it in production workloads? What about 
powerloss protection? From my understanding, thinlvm passes flushes 
anytime the higher layers issue them and so should be reasonable safe 
against unexpected powerloss. Is this view right?

2) use a classic (non-thin) LVM + normal snapshot + XFS. I know for sure 
that LV size is not an issue here, however big snapshot size used to be 
problematic: the CoW table had to be read completely before the snapshot 
can be activated. Is this problem a solved one? Or big snapshot can be 
problematic?

Thank you all.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti at assyoma.it - info at assyoma.it
GPG public key ID: FF5F32A8




More information about the linux-lvm mailing list