From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 0B29215815E for ; Thu, 8 Feb 2024 17:44:57 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 514BFE2A71; Thu, 8 Feb 2024 17:44:52 +0000 (UTC) Received: from smtp.hosts.co.uk (smtp.hosts.co.uk [85.233.160.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 02826E2A59 for ; Thu, 8 Feb 2024 17:44:51 +0000 (UTC) Received: from host86-152-228-249.range86-152.btcentralplus.com ([86.152.228.249] helo=[192.168.1.99]) by smtp.hosts.co.uk with esmtpa (Exim) (envelope-from ) id 1rY8SA-000000003Um-9kQa for gentoo-user@lists.gentoo.org; Thu, 08 Feb 2024 17:44:50 +0000 Message-ID: Date: Thu, 8 Feb 2024 17:44:50 +0000 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [gentoo-user] Re: Suggestions for backup scheme? Content-Language: en-GB To: gentoo-user@lists.gentoo.org References: <6028761.lOV4Wx5bFT@iris> <89a2a57b-761d-4cdf-b64c-7f876a37ef26@youngman.org.uk> <4547854.LvFx2qVVIh@iris> From: Wols Lists In-Reply-To: <4547854.LvFx2qVVIh@iris> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 4411cc2a-71b9-4302-b966-13e0b8d106c6 X-Archives-Hash: 4872f75127de4c5641da8ec4df2ceb37 On 08/02/2024 06:38, J. Roeleveld wrote: > ZFS doesn't have this "max amount of changes", but will happily fill up the > entire pool keeping all versions available. > But it was easier to add zpool monitoring for this on ZFS then it was to add > snapshot monitoring to LVM. > > I wonder, how do you deal with snapshots getting "full" on your system? As far as I'm, concerned, snapshots are read-only once they're created. But there is a "grow the snapshot as required" option. I don't understand it exactly, but what I think happens is when I create the snapshot it allocates, let's say, 1GB. As I write to the master copy, it fills up that 1GB with CoW blocks, and the original blocks are handed over to the backup snapshot. And when that backup snapshot is full of blocks that have been "overwritten" (or in reality replaced), lvm just adds another 1GB or whatever I told it to. So when I delete a snapshot, it just goes through those few blocks, decrements their use count (if they've been used in multiple snapshots), and if the use count goes to zero they're handed back to the "empty" pool. All I have to do is make sure that the sum of my snapshots does not fill the lv (logical volume). Which in my case is a raid-5. Cheers, Wol