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 ABD92630A5 for ; Tue, 14 Jul 2020 23:17:19 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id A1A4F29D47 for ; Tue, 14 Jul 2020 23:17:19 +0200 (CEST) Received: from mailpro.odiso.net (mailpro.odiso.net [89.248.211.110]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id A2C6829D3C for ; Tue, 14 Jul 2020 23:17:18 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mailpro.odiso.net (Postfix) with ESMTP id 9F363225EE20; Tue, 14 Jul 2020 23:17:16 +0200 (CEST) Received: from mailpro.odiso.net ([127.0.0.1]) by localhost (mailpro.odiso.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id A_BRJ9JnwyhU; Tue, 14 Jul 2020 23:17:16 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mailpro.odiso.net (Postfix) with ESMTP id 84F5E225EE21; Tue, 14 Jul 2020 23:17:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at mailpro.odiso.com Received: from mailpro.odiso.net ([127.0.0.1]) by localhost (mailpro.odiso.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id kh3zKTL_301H; Tue, 14 Jul 2020 23:17:16 +0200 (CEST) Received: from mailpro.odiso.net (mailpro.odiso.net [10.1.31.111]) by mailpro.odiso.net (Postfix) with ESMTP id 70C3C225EE20; Tue, 14 Jul 2020 23:17:16 +0200 (CEST) Date: Tue, 14 Jul 2020 23:17:16 +0200 (CEST) From: Alexandre DERUMIER To: Thomas Lamprecht Cc: Proxmox VE user list Message-ID: <1788232040.275836.1594761436288.JavaMail.zimbra@odiso.com> In-Reply-To: <0852a3fa-ab39-d551-5a01-0264687d4b56@proxmox.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Zimbra 8.8.12_GA_3866 (ZimbraWebClient - GC83 (Linux)/8.8.12_GA_3844) Thread-Topic: Proxmox Backup Server (beta) Thread-Index: vUxK6u5bcnp+c+itlXgtScXf6ki2/w== X-SPAM-LEVEL: Spam detection results: 0 KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_DNSWL_NONE -0.0001 Sender listed at https://www.dnswl.org/, no 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. [proxmox.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: Tue, 14 Jul 2020 21:17:19 -0000 >>Proxmox Backup Server effectively does that too, but independent from the >>source storage. We always get the last backup index and only upload the c= hunks >>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 i= s >>incremental either way. What happen if a vm or host crash ? (I think on clean shutdown, the dirty-b= itmap is saved, but on failure ?) does it need to re-read all blocks to find diff ? or make a new full backup= ? 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 beca= use of out of orders blocks) I really think it could be great to add some storage snapshot feature in th= e future. For ceph, the backup speed is really faster because it's done a bigger bloc= k than 64K. (I think it's 4MB object). and also, I really need a lot of space for my backups, and I can't fill the= m in a single local storage. (don't want to play with multiple datastores) Bonus, it could also be used for disaster recovery management :) But that seem really great for now, I known a lot of people that will be ha= ppy with PBS :) Congrats to all proxmox team ! ----- Mail original ----- De: "Thomas Lamprecht" =C3=80: "aderumier" , "Proxmox VE user list" Envoy=C3=A9: Mardi 14 Juillet 2020 17:52:41 Objet: Re: [PVE-User] Proxmox Backup Server (beta) Hi,=20 On 14.07.20 16:30, Alexandre DERUMIER wrote:=20 > I don't have tested it yet and read the full docs,=20 The following gives a quick overview:=20 https://pbs.proxmox.com/docs/introduction.html#main-features=20 >=20 > but it is possible to do ceph to ceph backup with ceph snapshots (instead= qemu bitmap tracking)?=20 No. ceph, or other storage snapshots, are not used for backup in PBS.=20 >=20 > Currently in production, we are backuping like that, with incremental sna= pshot,=20 >=20 > we keep X snapshots on ceph backup storage by vm, and production ceph clu= ster only keep the last snasphot.=20 >=20 > The main advantage, is that we are only doing a full backup once, then in= cremental backups forever.=20 > (and we have checkum verifications,encryption,...) on ceph backup=20 Proxmox Backup Server effectively does that too, but independent from the= =20 source storage. We always get the last backup index and only upload the chu= nks=20 which changed. For running VMs dirty-bitmap is on to improve this (avoids= =20 reading of unchanged blocks) but it's only an optimization - the backup is= =20 incremental either way.=20 > We can restore full block volume, but also selected files with mounting t= he volume with nbd.=20 There's a block driver for Proxmox Backup Server, so that should work just= =20 the same way.=20