From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 6750A1FF173 for ; Tue, 30 Jul 2024 08:51:13 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 811D4367BA; Tue, 30 Jul 2024 08:51:13 +0200 (CEST) In-Reply-To: <226084e0-f7a8-4d9c-9b0b-f8cdb1871549@proxmox.com> Date: Mon, 29 Jul 2024 17:29:34 -0400 References: <226084e0-f7a8-4d9c-9b0b-f8cdb1871549@proxmox.com> To: Fiona Ebner X-Mailman-Approved-At: Tue, 30 Jul 2024 08:51:12 +0200 MIME-Version: 1.0 Message-ID: List-Id: Proxmox VE development discussion List-Post: From: Jonathan Nicklin via pve-devel Precedence: list Cc: Jonathan Nicklin , Proxmox VE development discussion X-Mailman-Version: 2.1.29 X-BeenThere: pve-devel@lists.proxmox.com List-Subscribe: , List-Unsubscribe: , List-Archive: Reply-To: Proxmox VE development discussion List-Help: Subject: Re: [pve-devel] [RFC qemu/storage/qemu-server/container/manager 00/23] backup provider API Content-Type: multipart/mixed; boundary="===============7703095004822746608==" Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" --===============7703095004822746608== Content-Type: message/rfc822 Content-Disposition: inline Return-Path: X-Original-To: pve-devel@lists.proxmox.com Delivered-To: pve-devel@lists.proxmox.com 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 960ECC08ED for ; Mon, 29 Jul 2024 23:30:15 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 7454E326AC for ; Mon, 29 Jul 2024 23:29:45 +0200 (CEST) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Mon, 29 Jul 2024 23:29:43 +0200 (CEST) Received: by mail-qk1-x731.google.com with SMTP id af79cd13be357-7a1e31bc1efso213610885a.3 for ; Mon, 29 Jul 2024 14:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blockbridge.com; s=google; t=1722288575; x=1722893375; darn=lists.proxmox.com; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=8ELp8oY7C6N0QcLlfBdDOg3H7pfC2m9WEy0/e8cBwxU=; b=xlf3GhB/BjI3ewQ6l30dPIhIx/56W6nH5NYtubVMEocF+R5dPXogm3I8LzS4d66F76 d/gxb5y/7vJ9BHpvDXC0NUp+nmClSYTjoreHUpw644BV8VEoCM/0QR3cduSMgpis08z6 ZUSpqE9LgveqZpZaQMaurP2LiGSZ+IMckEdk2RPFEdQznpkXJFk/B6gFjNM8CcN1I/by fLVuk13ezjmlI6snxBWkRc80r57mPCeU+VMxlEmBSkoPJRJv4LYD7VHGXn50kTlZVyQ0 E0IrazbgWpWIc74oJMfYRz/TySwmHdJezBgtUUgX6Yw1LrAGqWtk2aMKYn8cnQW08mvi zX5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722288575; x=1722893375; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=8ELp8oY7C6N0QcLlfBdDOg3H7pfC2m9WEy0/e8cBwxU=; b=o7nny/1Bz0sY0WSvdhehVlMl/GWgefTEVRvOtsXASTI91eVeb+xeBvBB8Qx+4cLKF+ l3rjkM9ckP2HbPqclo47X1QbUDBzn2VCdGzHkDuWiAuPe0umE1BMT9XKm/8JYL3KPlAV 7ZwZI+DWORGy03OndzpNA+8SC1fIczd+UOWEPQcIfKcnx/CMrtN3idd27MkaAJHLtHmO 9vCzhZX4qOJxhexb48E2DY7NnTYtTEC9REoChK98YNjZ6v9je/51NB47SQ3rkjHf/gBt CAbmDyIqYB5HwdmSv3g7PKH5tE4bnzGs6UI1RgsQ46cvLEl3oq6Bj5CEjlGD4gNXlGUJ w49Q== X-Gm-Message-State: AOJu0Yyq4jgfaR3excGXla8qsHyVH5/AEqSNzWONSmYDHOFSvNaYwIcE xLytWZemvisV38S21SFt/OmDBzwLi74PMay8bmxlfcBFJnRwTcSF6v1zUrBwr3ScQDkDrIZv9C/ A X-Google-Smtp-Source: AGHT+IF7jw+W1oHGYyrUZzlZEZc/FbScqaz2Q+NotcZnKYcfnTsh38y9WN2/bhWQiEY+RjdE6cGxng== X-Received: by 2002:a05:620a:1a02:b0:79f:4e8:a657 with SMTP id af79cd13be357-7a1e52f37d1mr1242585985a.61.1722288575428; Mon, 29 Jul 2024 14:29:35 -0700 (PDT) Received: from smtpclient.apple (pool-108-7-52-138.bstnma.fios.verizon.net. [108.7.52.138]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7a1d73ea980sm568977385a.59.2024.07.29.14.29.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jul 2024 14:29:35 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Subject: Re: [pve-devel] [RFC qemu/storage/qemu-server/container/manager 00/23] backup provider API From: Jonathan Nicklin In-Reply-To: <226084e0-f7a8-4d9c-9b0b-f8cdb1871549@proxmox.com> Date: Mon, 29 Jul 2024 17:29:34 -0400 Cc: Proxmox VE development discussion Content-Transfer-Encoding: quoted-printable Message-Id: <5041A106-1A29-459C-AEDC-8531524ACA18@blockbridge.com> References: <226084e0-f7a8-4d9c-9b0b-f8cdb1871549@proxmox.com> To: Fiona Ebner X-Mailer: Apple Mail (2.3693.20.0.1.32) X-SPAM-LEVEL: Spam detection results: 0 AWL 0.115 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain DMARC_PASS -0.1 DMARC pass policy 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 X-Mailman-Approved-At: Tue, 30 Jul 2024 08:51:12 +0200 I 100% concur. I am not suggesting any breaking changes; I was just = wondering if this work on the API unlocked any new optimizations to make = the interactions between the backup client, PBS, and storage more = efficient. And also, bbgeek has pinged me to check out the awesome work = going on in this space :) Between your and Dietmar's replies, I see the constraints and potential = avenues for improvement. Thanks for your reply! Respectfully, -Jonathan > On Jul 29, 2024, at 4:15 AM, Fiona Ebner wrote: >=20 > Hi, >=20 > Am 26.07.24 um 21:47 schrieb Jonathan Nicklin via pve-devel: >>=20 >> Hi Fiona, >>=20 >> Would adding support for offloading incremental difference detection >> to the underlying storage be feasible with the API updates? The QEMU >> bitmap strategy works for all storage devices but is far from >> optimal. If backup coordinated a storage snapshot, the underlying >> storage could enumerate the differences (or generate a bitmap). >>=20 >> This would allow PBS to connect directly to storage and retrieve >> incremental differences, which could remove the PVE hosts from the >> equation. This "storage-direct" approach for backup would improve >> performance, reduce resources, and support incremental backups in all >> cases (i.e., power failues, shutdowns, etc.). It would also eliminate >> the dependency on QEMU bitmaps and the overhead of fleecing. >>=20 >> Theoretically, this should be possible with any shared storage that >> can enumerate incremental differences between snapshots: Ceph, >> Blockbridge, iSCSi/ZFS? >>=20 >> Thoughts? >>=20 >=20 > The two big advantages of the current mechanism are: >=20 > 1. it's completely storage-agnostic, so you can even use it with raw > files on a directory storage. It follows in the same spirit as = existing > backup. Prohibiting backup for users when they use certain kinds of > storages for VMs is not nice. > 2. it's been battle-tested with PBS and works nicely. >=20 > I don't see why your suggestion can't be implemented in principle. > Feature requests for (non-incremental) "storage-snapshot" mode backup > have been around since a while. It was not a priority for development > yet and is totally different from the current "snapshot" backup mode, = so > will need to be developed from the ground up. >=20 > That said, AFAICS, it's orthogonal to the series here. When an > implementation like you outlined exists, it can just be added as a new > backup mechanism for external providers (and PBS). >=20 > See also the related discussion over at: > https://bugzilla.proxmox.com/show_bug.cgi?id=3D3233#c19 >=20 > Best Regards, > Fiona >=20 --===============7703095004822746608== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel --===============7703095004822746608==--