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 738348BA97 for ; Fri, 26 Aug 2022 10:17:19 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 692FB2D79A for ; Fri, 26 Aug 2022 10:17:19 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (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 for ; Fri, 26 Aug 2022 10:17:18 +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 91E39434E2 for ; Fri, 26 Aug 2022 10:09:22 +0200 (CEST) From: Dominik Csapak To: pbs-devel@lists.proxmox.com Date: Fri, 26 Aug 2022 10:09:20 +0200 Message-Id: <20220826080921.1678212-3-d.csapak@proxmox.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20220826080921.1678212-1-d.csapak@proxmox.com> References: <20220826080921.1678212-1-d.csapak@proxmox.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.093 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - Subject: [pbs-devel] [PATCH proxmox-backup 3/4] docs: technical overview: add section about snapshots X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2022 08:17:19 -0000 to clarify that snapshots get uploaded in an incremental manner, but still represent a full backup. Signed-off-by: Dominik Csapak --- docs/technical-overview.rst | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/docs/technical-overview.rst b/docs/technical-overview.rst index 59a59c11..f3e25b59 100644 --- a/docs/technical-overview.rst +++ b/docs/technical-overview.rst @@ -18,6 +18,27 @@ referenced by the indexes in a backup snapshot. This means that multiple indexes can reference the same chunks, reducing the amount of space needed to contain the data (even across backup snapshots). +Snapshots +--------- + +A Snapshot is the collection of manifest, blobs and indexes that represent +a backup. When a client creates a snapshot, it can upload blobs (single files +which are not chunked, e.g. the client log), or one or more indexes +(fixed or dynamic). + +When uploading an index, the client first has to read the source data, chunk it +and send the data as chunks with their identifying checksum to the server. + +If there is a previous Snapshot in the backup group, the client can first +download the chunk list of the previous Snapshot. If it detects a chunk that +already exists on the server, it can send only the checksum instead of data +and checksum. This way the actual upload of Snapshots is incremental while +each Snapshot references all chunks and is thus a full backup. + +After uploading all data, the client has to signal to the server that the +backup is finished. If that is not done before the connection closes, the +server will remove the unfinished snapshot. + Chunks ------ -- 2.30.2