From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx1.redhat.com (ext-mx10.extmail.prod.ext.phx2.redhat.com [10.5.110.39]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B53BB60F83 for ; Fri, 7 Apr 2017 18:21:41 +0000 (UTC) Received: from mail-lf0-f53.google.com (mail-lf0-f53.google.com [209.85.215.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DC6FF624A4 for ; Fri, 7 Apr 2017 18:21:38 +0000 (UTC) Received: by mail-lf0-f53.google.com with SMTP id z15so46249102lfd.1 for ; Fri, 07 Apr 2017 11:21:38 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1438f48b-0a6d-4fb7-92dc-3688251e0a00@assyoma.it> References: <1438f48b-0a6d-4fb7-92dc-3688251e0a00@assyoma.it> From: =?UTF-8?Q?Tomas_Dalebj=C3=B6rk?= Date: Fri, 7 Apr 2017 20:21:36 +0200 Message-ID: Content-Type: multipart/alternative; boundary=94eb2c1cd53c3679b6054c97b2b7 Subject: Re: [linux-lvm] Snapshot behavior on classic LVM vs ThinLVM Reply-To: LVM general discussion and development List-Id: LVM general discussion and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , List-Id: To: LVM general discussion and development --94eb2c1cd53c3679b6054c97b2b7 Content-Type: text/plain; charset=UTF-8 Hi Agent less snapshot of the vm server might be an issue with application running in the vm guest os. Especially as there are no VSS like features on linux. Perhaps someone can introduce a udev listener that can be used? Den 6 apr. 2017 16:32 skrev "Gionatan Danti" : > 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@assyoma.it - info@assyoma.it > GPG public key ID: FF5F32A8 > > _______________________________________________ > linux-lvm mailing list > linux-lvm@redhat.com > https://www.redhat.com/mailman/listinfo/linux-lvm > read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/ > --94eb2c1cd53c3679b6054c97b2b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi

Agent les= s snapshot of the vm server might be an issue with application running in t= he vm guest os.
Especially as there are no VSS like = features on linux.

Perha= ps someone can introduce a udev listener that can be used?

Den 6 apr. 2017 16:32 = skrev "Gionatan Danti" <= g.danti@assyoma.it>:
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)?<= br>
Long story:
In the past, I used classical, preallocated logical volumes directly export= ed as virtual disks. In this case, I snapshot the single LV I want to backu= p and, using dd/ddrescue, I copy it.

Problem is this solution prevents any use of thin allocation or sparse file= s, so I tried to replace it with something filesystem-based. Lately I used = another approach, configuring a single thinly provisioned LV (with no zeroi= ng) + XFS + raw or qcow2 virtual machine images. To make backups, I snapsho= tted 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 s= omething 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 prot= ection? From my understanding, thinlvm passes flushes anytime the higher la= yers issue them and so should be reasonable safe against unexpected powerlo= ss. Is this view right?

2) use a classic (non-thin) LVM + normal snapshot + XFS. I know for sure th= at LV size is not an issue here, however big snapshot size used to be probl= ematic: 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@assy= oma.it - info@assy= oma.it
GPG public key ID: FF5F32A8

_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.= com
https://www.redhat.com/mailman/listinfo/linux-= lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
--94eb2c1cd53c3679b6054c97b2b7--