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) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id CEEEE6312A for ; Wed, 15 Jul 2020 06:52:54 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id BC9452BD50 for ; Wed, 15 Jul 2020 06:52:54 +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) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id E34752BD36 for ; Wed, 15 Jul 2020 06:52:52 +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 B01304304F; Wed, 15 Jul 2020 06:52:52 +0200 (CEST) To: Alexandre DERUMIER Cc: Proxmox VE user list References: <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> <1788232040.275836.1594761436288.JavaMail.zimbra@odiso.com> From: Thomas Lamprecht Message-ID: Date: Wed, 15 Jul 2020 06:52:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.0 MIME-Version: 1.0 In-Reply-To: <1788232040.275836.1594761436288.JavaMail.zimbra@odiso.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.005 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 URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [ceph.com] 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: Wed, 15 Jul 2020 04:52:54 -0000 On 14.07.20 23:17, Alexandre DERUMIER wrote: >>> Proxmox Backup Server effectively does that too, but independent from the >>> source storage. We always get the last backup index and only upload the chunks >>> which changed. For running VMs dirty-bitmap is on to improve this (avoids >>> reading of unchanged blocks) but it's only an optimization - the backup is >>> incremental either way. > > What happen if a vm or host crash ? (I think on clean shutdown, the dirty-bitmap is saved, but on failure ?) > does it need to re-read all blocks to find diff ? or make a new full backup ? There's never a new "full backup" as long as the PBS has at least one. But yes, it needs to re-read everything to get the diff for the first backup after the VM process starts, from then the tracking is active again. > > Is it possible to read files inside a vm backup, without restoring it first ? > (Don't have check vma format recently, but I think it was not possible because of out of orders blocks) There's support for block and file level backup, CTs are using a file level backup, you can then even browse the backup on the server (if it's not encrypted) As said, there's a block backend driver for it in QEMU, Stefan made it with Dietmar's libproxmox-backup-qemu0 library. So you should be able to get a backup as block device over NBD and mount it, I guess. (did not tried that yet fully myself). > > I really think it could be great to add some storage snapshot feature in the future. The storage would need to allow us diffing from the outside between the previous snapshot and the current state though, not sure where that's possible in such away that it could be integrated into PBS in a reasonable way. The ceph RBD diff format wouldn't seem to bad, though: https://docs.ceph.com/docs/master/dev/rbd-diff/ > For ceph, the backup speed is really faster because it's done a bigger block than 64K. (I think it's 4MB object). We use 4MiB chunks for block-level backup by default too, for file-level they're dynamic and scale between 64KiB and 4MiB. > and also, I really need a lot of space for my backups, and I can't fill them in a single local storage. (don't want to play with multiple datastores) What are your (rough) space requirements? You could always attach a big CephFS or RBD device with local FS as a storage too. Theoretically PBS could live on your separate "backup only" ceph cluster node, or be directly attached to it over 25 to 100G. > Bonus, it could also be used for disaster recovery management :) Something like that would be nice, what's in your mind for your use case?