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 12F9962B11 for ; Tue, 24 Nov 2020 12:21:41 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 09D28B26D for ; Tue, 24 Nov 2020 12:21:41 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [212.186.127.180]) (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 3EC68B262 for ; Tue, 24 Nov 2020 12:21: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 08480404F6 for ; Tue, 24 Nov 2020 12:21:40 +0100 (CET) To: Proxmox Backup Server development discussion , Oguz Bektas References: <20201124105205.218623-1-o.bektas@proxmox.com> From: Thomas Lamprecht Message-ID: <6aac0308-4cdb-a7ac-c52f-856d08f0befb@proxmox.com> Date: Tue, 24 Nov 2020 12:21:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:83.0) Gecko/20100101 Thunderbird/83.0 MIME-Version: 1.0 In-Reply-To: <20201124105205.218623-1-o.bektas@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL -0.083 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment KAM_SHORT 0.001 Use of a URL Shortener for very short URL NICE_REPLY_A -0.001 Looks like a legit reply (A) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [leo.org, wiktionary.org, dict.cc, wikipedia.org] Subject: Re: [pbs-devel] [PATCH proxmox-backup] docs: fix typos in maintenance section 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, 24 Nov 2020 11:21:41 -0000 On 24.11.20 11:52, Oguz Bektas wrote: > Signed-off-by: Oguz Bektas > --- > docs/maintenance.rst | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) thanks, a comment about reverify below =20 > diff --git a/docs/maintenance.rst b/docs/maintenance.rst > index 561b4fe4..8a90d5f6 100644 > --- a/docs/maintenance.rst > +++ b/docs/maintenance.rst > @@ -48,7 +48,7 @@ Prune Simulator > ^^^^^^^^^^^^^^^ > =20 > You can use the built-in `prune simulator = `_ > -to explore the effect of different retetion options with various backu= p > +to explore the effect of different retention options with various back= up > schedules. > =20 > Manual Pruning > @@ -147,13 +147,13 @@ snapshots are ignored, as well as set a time peri= od, after which verified jobs > are checked again. The interface for creating verify jobs can be found= under the > **Verify Jobs** tab of the datastore. > =20 > -.. Note:: It is recommended that you reverify all backups at least mon= thly, even > - if a previous verification was successful. This is becuase physical = drives > +.. Note:: It is recommended that you re-verify all backups at least mo= nthly, even "reverify" seems to be just fine though, at least I find so many referenc= es in various dictionaries/articles that I do not think this requires change= =2E https://www.dict.cc/?s=3Dreverify https://dict.leo.org/englisch-deutsch/reverify https://en.wiktionary.org/wiki/reverify https://en.wikipedia.org/wiki/Reverification > + if a previous verification was successful. This is because physical = drives > are susceptible to damage over time, which can cause an old, working= backup > to become corrupted in a process known as `bit rot/data degradation > `_. It is good pract= ice to > have a regularly recurring (hourly/daily) verification job, which ch= ecks new > - and expired backups, then another weekly/monthly job that will rever= ify > + and expired backups, then another weekly/monthly job that will re-ve= rify same here > everything. This way, there will be no surprises when it comes to re= storing > data. > =20 >=20