From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 826D11FF15C for ; Wed, 13 Nov 2024 14:50:36 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 74564165A6; Wed, 13 Nov 2024 14:50:37 +0100 (CET) Date: Wed, 13 Nov 2024 14:50:00 +0100 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= To: Proxmox Backup Server development discussion References: <20241031154554.585068-1-c.ebner@proxmox.com> In-Reply-To: <20241031154554.585068-1-c.ebner@proxmox.com> MIME-Version: 1.0 User-Agent: astroid/0.16.0 (https://github.com/astroidmail/astroid) Message-Id: <1731505125.0cl85561ct.astroid@yuna.none> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.047 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy 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 Subject: Re: [pbs-devel] [PATCH proxmox-backup 1/2] docs: add security implications of prune and change detection mode 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: , Reply-To: Proxmox Backup Server development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pbs-devel-bounces@lists.proxmox.com Sender: "pbs-devel" On October 31, 2024 4:45 pm, Christian Ebner wrote: > Users should be made aware that the data stored in chunks outlives > the backup snapshots on pruning and that backups created using the > change-detection-mode set to metadata might reference chunks > containing files which have vanished since the previous backup, but > might still be accessible when access to the chunks raw data is > possible (client or server side). > > Signed-off-by: Christian Ebner > --- > docs/maintenance.rst | 23 +++++++++++++++++++++-- > 1 file changed, 21 insertions(+), 2 deletions(-) > > diff --git a/docs/maintenance.rst b/docs/maintenance.rst > index 4bb135e4e..b6d42ecc2 100644 > --- a/docs/maintenance.rst > +++ b/docs/maintenance.rst > @@ -6,8 +6,27 @@ Maintenance Tasks > Pruning > ------- > > -Prune lets you specify which backup snapshots you want to keep. > -The following retention options are available: > +Prune lets you specify which backup snapshots you want to keep, removing others. > +For removed backups, only the metadata associating the snapshot with the data this is a bit hard to parse (if you don't already know what it means) how about: When removing snapshots, only the snapshot metadata (manifest, indices, blobs, log and notes) is removed, the chunks containing the actual backup data referenced by the snapshot indices have to be removed by a garbage collection run. > +stored in the data chunks is removed, the actual backup data has to be removed > +by garbage collection. > + > +.. Caution:: Take into consideration that sensitive information stored in data > + chunks will outlive a pruned snapshot and remain present in the datastore as > + long as at least one backup snapshot references this data. > + > + If no longer referenced, the data remains until removed by the garbage > + collection. *Even* if no snapshot references a given chunk, it will remain.. > + > + Further, backups created using the `change-detection-mode` set to `metadata` > + might reference backup chunks containing files which have vanished since the > + previous backup, but might still be accessible when reading the chunks raw > + data is possible (client or server side). > + > + Creating a backup with `change-detection-mode` set to `data` will break this > + chain, as files will never reuse chunks partially. This is a bit unclear IMHO. if we want to give instructions on what to do when sensitive data ended up in a backup, they should be complete: - prune any snapshots made while the sensitive data was part of the backup input - if using file-based backups with change-detection-mode metadata: -- additionally prune all snapshots since the sensitive data was removed from the backup input - trigger a GC run the change-detection-mode data would break the chain, but not remove all affected snapshots. if all affected snapshots are removed, there is no need for change-detection-mode data? in fact, not using it might be better -> there might be a snapshot before the sensitive data was added to the input that can still serve as a valid baseline for metadata-using change detection? > + > +The following retention options are available for pruning: > > ``keep-last `` > Keep the last ```` backup snapshots. > -- > 2.39.5 > > > > _______________________________________________ > pbs-devel mailing list > pbs-devel@lists.proxmox.com > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel > > > _______________________________________________ pbs-devel mailing list pbs-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel