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

[Gionatan Danti]

On 06/04/2017 16:31, Gionatan Danti wrote:
> 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.
>

Hi,
anyone with other thoughts on the matter?

Thanks.

-- 
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