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 3B5C864113 for ; Tue, 1 Mar 2022 12:40:11 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 298DA1EC99 for ; Tue, 1 Mar 2022 12:39:41 +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)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 14E7E1EC8F for ; Tue, 1 Mar 2022 12:39:40 +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 DB3B7460D0 for ; Tue, 1 Mar 2022 12:39:39 +0100 (CET) Message-ID: <255802b8-48f3-af58-5260-64af184b94f6@proxmox.com> Date: Tue, 1 Mar 2022 12:39:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:98.0) Gecko/20100101 Thunderbird/98.0 Content-Language: en-US To: Proxmox Backup Server development discussion , Dominik Csapak References: <20220228112008.3364833-1-d.csapak@proxmox.com> <20220228112008.3364833-2-d.csapak@proxmox.com> From: Thomas Lamprecht In-Reply-To: <20220228112008.3364833-2-d.csapak@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.059 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 NICE_REPLY_A -0.001 Looks like a legit reply (A) 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 - 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: [pbs-devel] [PATCH proxmox-backup v2 2/2] docs: add tape schedule examples 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: Tue, 01 Mar 2022 11:40:11 -0000 On 28.02.22 12:20, Dominik Csapak wrote: > just a few examples how one could configure tape pools and jobs. > > Signed-off-by: Dominik Csapak > --- > changes from v1: > * clarified how to manually trigger a new media-set in the simplest case > * reworded last example by removing 'rotation' (if a tape is rotated > depends on how many tapes there are in the pool) > some wording/typo/grammar comments inline > docs/tape-backup.rst | 74 ++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 74 insertions(+) > > diff --git a/docs/tape-backup.rst b/docs/tape-backup.rst > index ae597d3d..5d4ce444 100644 > --- a/docs/tape-backup.rst > +++ b/docs/tape-backup.rst > @@ -979,3 +979,77 @@ This command does the following: > - run drive cleaning operation > > - unload the cleaning tape (to slot 3) > + > +Example Setups > +-------------- > + > +Here are a few example setups for how to manage media pools and schedules. > +This is not an exhaustive list, and there are many more possible combinations > +of useful settings. > + > +Simple Setup > +~~~~~~~~~~~~ > + Not that hard feelings, but "simple setup" is not really telling. "Continuously Incremental Keep" isn't that nice either but at least a bit less ominous, maybe you got a better idea: > +The most simple setup, always continue the media-set and never expire. Either s/,/:/ or The most simple setup is to always continue the media-set and never let it expire. > +All backups are stored on a single media set and never deleted. IMO first part superfluous and the never being deleted is a bit weird in context of tapes which cannot be deleted anyway, I'd just drop that sentence and add a bit more context below. > + > +Allocation policy: > + continue > + > +Retention policy: > + keep > + > +Such a simple setup has the advantage that it uses not much space, and maybe: That setup had the advantage of being easy to manage and re-using the benefits from deduplication as much as possible. But, it's also prone to a failure of any single tape, which would render all backups referring to chunks from that tape unusable. > +since there is only one media-set, it is easy to manage. On the other hand, > +it is prone to errors. If a single tape fails, all backups that uses chunks > +from that tape will not be restorable. If you want to start a new media-set > +manually, you can set the currently writable media of the set either to > +'full', or set the location to an offsite vault. In that case, a new > +media-set will be created. Feels a bit redundant, the sentence before that already starts with "If you want to start a new media-set" > + > +Weekday Scheme > +~~~~~~~~~~~~~~ > + > +A slightly more complex scheme, where the goal is to have a tape for each maybe add "independent", like: "... to have an independent tape ..." > +weekday, e.g. from Monday to Friday. This can be solved by having a seperate separate Our technical writing style guide recommends to avoid "e.g.": https://intranet.proxmox.com/index.php/Technical_Writing_Style_Guide#e.g..2Fi.e. > +media pool for each day, so 'Monday', 'Tuesday', etc. > + > +Allocation policy: > + should be 'mon' for the 'Monday' pool, 'tue' for the Tuesday pool and so on. > + > +Retention policy: > + overwrite > + > +There should be a (or more) tape-backup jobs for each pool on the correspondig corresponding > +weekday. This scheme is still easily managable with one media set per weekday, manageable > +which can even be taken off site easily. easily twice in the same sentence sounds a bit off. > + > +Staggered Pools > +~~~~~~~~~~~~~~~ staggered sounds a bit hard to understand for a user > + > +Alternatively, more complex setups are possible with multiple media pools and > +different allocation and retention policies. > + > +An example would be to have a media pool with weekly allocation: I'd start off with mentioning both pools so that the user has it already in mind when reading, for example the whole section could be roughly: An example would be to have two media pools, one with weekly allocation: Allocation Policy: ... And another one with yearly allocation that does not expire: ... In combination with suited, ... > + > +Allocation policy: > + mon > + > +Retention policy: > + 3 weeks > + > +This creates a new media set each week, and expires them after the 4th > +media set. > + > +Then in addition, there could be a yearly pool that only gets allocated > +once a year, but will not be expired (e.g. for long-term archival purposes): > + > +Allocation policy: > + yearly > + > +Retention policy: > + keep > + > +In combination with suited prune settings and tape backup schedules, this > +achieves long-term storage of some backups, while keeping the current > +backups on smaller media sets that get expired every 4 weeks.