all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox Backup Server development discussion
	<pbs-devel@lists.proxmox.com>, Oguz Bektas <o.bektas@proxmox.com>
Subject: Re: [pbs-devel] [PATCH proxmox-backup] docs: fix typos in maintenance section
Date: Tue, 24 Nov 2020 12:21:38 +0100	[thread overview]
Message-ID: <6aac0308-4cdb-a7ac-c52f-856d08f0befb@proxmox.com> (raw)
In-Reply-To: <20201124105205.218623-1-o.bektas@proxmox.com>

On 24.11.20 11:52, Oguz Bektas wrote:
> Signed-off-by: Oguz Bektas <o.bektas@proxmox.com>
> ---
>  docs/maintenance.rst | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)

thanks, a comment about reverify below  

> 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
>  ^^^^^^^^^^^^^^^
>  
>  You can use the built-in `prune simulator <prune-simulator/index.html>`_
> -to explore the effect of different retetion options with various backup
> +to explore the effect of different retention options with various backup
>  schedules.
>  
>  Manual Pruning
> @@ -147,13 +147,13 @@ snapshots are ignored, as well as set a time period, after which verified jobs
>  are checked again. The interface for creating verify jobs can be found under the
>  **Verify Jobs** tab of the datastore.
>  
> -.. Note:: It is recommended that you reverify all backups at least monthly, even
> -  if a previous verification was successful. This is becuase physical drives
> +.. Note:: It is recommended that you re-verify all backups at least monthly, even


"reverify" seems to be just fine though, at least I find so many references
in various dictionaries/articles that I do not think this requires change.

https://www.dict.cc/?s=reverify
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
>    <https://en.wikipedia.org/wiki/Data_degradation>`_. It is good practice to
>    have a regularly recurring (hourly/daily) verification job, which checks new
> -  and expired backups, then another weekly/monthly job that will reverify
> +  and expired backups, then another weekly/monthly job that will re-verify

same here

>    everything. This way, there will be no surprises when it comes to restoring
>    data.
>  
> 






      reply	other threads:[~2020-11-24 11:21 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-24 10:52 Oguz Bektas
2020-11-24 11:21 ` Thomas Lamprecht [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6aac0308-4cdb-a7ac-c52f-856d08f0befb@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=o.bektas@proxmox.com \
    --cc=pbs-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal