From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (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 lists.proxmox.com (Postfix) with ESMTPS id 53E08641E8 for ; Sat, 18 Jul 2020 20:07:41 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 4720B23708 for ; Sat, 18 Jul 2020 20:07:41 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [212.186.127.180]) (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 firstgate.proxmox.com (Proxmox) with ESMTPS id AAD09236FA for ; Sat, 18 Jul 2020 20:07:40 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 658864319C; Sat, 18 Jul 2020 20:07:40 +0200 (CEST) To: Proxmox VE user list , Tom Weber References: <7d1bd7a4-f47b-4a1a-9278-ff1889508c33@gmail.com> <1768587204.461.1594383204281@webmail.proxmox.com> <450971473.487.1594395714078@webmail.proxmox.com> <1514606299.525.1594478405167@webmail.proxmox.com> <16057806.272035.1594737045788.JavaMail.zimbra@odiso.com> <0852a3fa-ab39-d551-5a01-0264687d4b56@proxmox.com> <4b7e3a23d9b1f41ef51e6363373072d265797380.camel@junkyard.4t2.com> <1594969118.mb1771vpca.astroid@nora.none> <1edc84ae5a9b082c5744149ce7d3e0dfdc32a2ae.camel@junkyard.4t2.com> <97c35a8e-eeb6-1d49-6a09-bc7f367f89dc@proxmox.com> <0c115f31d30593e8f169ef6c6418128bbdb1435a.camel@junkyard.4t2.com> From: Thomas Lamprecht Message-ID: <9dc7fbd9-867e-ae29-bd35-541a4bb201ac@proxmox.com> Date: Sat, 18 Jul 2020 20:07:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:79.0) Gecko/20100101 Thunderbird/79.0 MIME-Version: 1.0 In-Reply-To: <0c115f31d30593e8f169ef6c6418128bbdb1435a.camel@junkyard.4t2.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.008 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.001 Looks like a legit reply (A) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [PVE-User] Proxmox Backup Server (beta) X-BeenThere: pve-user@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE user list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2020 18:07:41 -0000 On 18.07.20 16:59, Tom Weber wrote: > Am Freitag, den 17.07.2020, 19:43 +0200 schrieb Thomas Lamprecht: >> If a backup fails, or the last backup index we get doesn't matches >> the >> checksum we cache in the VM QEMU process we drop the bitmap and do >> read >> everything (it's still send incremental from the index we got now), >> and >> setup a new bitmap from that point. > > ah, I think I start to understand (read a bit about the qemu side too > now) :) > > So you keep some checksum/signature of a successfull backup run with > the one (non-persistant) dirty bitmap in qemu. > The next backup run can check this and only makes use of the bitmap if > it matches else it will fall back to reading and comparing all qemu > blocks against the ones in the backup - saving only the changed ones? Exactly. > First of all, that noted backup scenario was not designed for a > blocklevel incremental backup like pbs is meant. I don't know yet if > I'd do it like this for pbs. But it probably helps to understand why it > raised the above question. > > If the same "area" of data changes everyday, say 1GB, and I do > incremental backups and have like 10GB of space for that on 2 > independent Servers. > Doing that incremental Backup odd/even to those 2 Backupservers, I end > up with 20 days of history whereas with 2 syncronized Backupservers > only 10 days of history are possible (one could also translate this in > doubled backup space ;) ). Yeah if only the same disk blocks are touched the math would work out. But you've doubled the risk of loosing the most recent backup, that's the price. But you do you, I'd honestly just check it out and test around a bit to see how it really behaves for your use case and setup behavior and limitations. cheers, Thomas