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 23A4263D4C for ; Mon, 28 Feb 2022 12:20:41 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 156B3600D for ; Mon, 28 Feb 2022 12:20:11 +0100 (CET) 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) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 0053C5FF8 for ; Mon, 28 Feb 2022 12:20:09 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id C64DF41C56 for ; Mon, 28 Feb 2022 12:20:09 +0100 (CET) From: Dominik Csapak To: pbs-devel@lists.proxmox.com Date: Mon, 28 Feb 2022 12:20:07 +0100 Message-Id: <20220228112008.3364833-1-d.csapak@proxmox.com> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.156 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 v2 1/2] docs: explain retention time for event allocation policy in more detail 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: Mon, 28 Feb 2022 11:20:41 -0000 'when the calendar event' triggers was too vague, it could mean for the current media-set or the next time. Apart from that, it was not technically correct all the time, since we take the start time of the next media set if that exists first. The idea here is that we begin the retention when the media set is finished. Signed-off-by: Dominik Csapak --- docs/tape-backup.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/tape-backup.rst b/docs/tape-backup.rst index a8d6b7fd..ae597d3d 100644 --- a/docs/tape-backup.rst +++ b/docs/tape-backup.rst @@ -519,8 +519,9 @@ a single media pool, so a job only uses tapes from that pool. This balances between space efficiency and media count. - .. NOTE:: Retention period starts when the calendar event - triggers. + .. NOTE:: Retention period starts on the creation time of the next + media-set or, if that does not exist, when the calendar event + triggers the next time after the current media-set start time. Additionally, the following events may allocate a new media set: -- 2.30.2