summaryrefslogtreecommitdiff
path: root/manual/en
diff options
context:
space:
mode:
authorLars Wirzenius <liw@liw.fi>2014-06-25 21:41:52 +0100
committerLars Wirzenius <liw@liw.fi>2014-06-25 21:41:52 +0100
commit58bfac863fea033187a63eabd7ea8cea048adcc1 (patch)
treea15b0261224e7172e800a73cc636b4a9266283e4 /manual/en
parent97703607d85451c484dd1e30f6d2ceeff05df3b2 (diff)
downloadobnam-58bfac863fea033187a63eabd7ea8cea048adcc1.tar.gz
Fix some spelling mistakes in the manual
Diffstat (limited to 'manual/en')
-rw-r--r--manual/en/020-concepts.mdwn10
-rw-r--r--manual/en/050-quick-tour.mdwn2
-rw-r--r--manual/en/060-backing-up.mdwn12
-rw-r--r--manual/en/070-restoring.mdwn2
-rw-r--r--manual/en/080-forgetting.mdwn6
-rw-r--r--manual/en/090-verifiying.mdwn6
-rw-r--r--manual/en/110-encryption.mdwn10
-rw-r--r--manual/en/150-config.mdwn2
8 files changed, 25 insertions, 25 deletions
diff --git a/manual/en/020-concepts.mdwn b/manual/en/020-concepts.mdwn
index d494e1b9..2e817e5e 100644
--- a/manual/en/020-concepts.mdwn
+++ b/manual/en/020-concepts.mdwn
@@ -47,7 +47,7 @@ The place your backups are stored is the **backup repository**. You can
use many kinds of **backup media** for backup storage: hard drives,
tapes, optical disks (DVD-R, DVD-RW, etc), USB flash drives, online
storage, etc. Each type of medium has different characteristics:
-size, speed, convenicence, reliability, price, which you'll need to
+size, speed, convenience, reliability, price, which you'll need to
balance for a backup solution that's reasonable for you.
You may need multiple backup repositories or media, with one of
@@ -229,8 +229,8 @@ reliability, speed, and price, and they may fluctuate fairly quickly
from week to week and year to year. We won't go into detailed
comparisons of all the options. From Obnam's point of view, anything
that can look like a hard drive (spinning rust, SSD, USB flash memory
-stick, or online storage) is useable for storing backups, as long as
-it is re-writeable.
+stick, or online storage) is usable for storing backups, as long as
+it is re-writable.
**Optical disks**, particularly the kind that are write-once and can't
be updated, can be used for backup storage, but they tend to be best
@@ -250,7 +250,7 @@ that is easy to OCR), or using two-dimensional barcode (e.g, QR).
Obnam doesn't support these, either.
Obnam only works with hard drives, and anything that can simulate a
-read/writeable hard drive, such as online storage. By amazing
+read/writable hard drive, such as online storage. By amazing
co-incidence, this seems to be sufficient for most people.
Glossary
@@ -278,7 +278,7 @@ Glossary
from the live data
* **precious data**: all the data you care about; cf. live data
* **repository**: the location where are backups are stored
-* **restore**: retriving data from a backup repository
+* **restore**: retrieving data from a backup repository
* **root**, **backup root**: a directory that is to be backed up,
including all files in it, and all its subdirectories
* **snapshot backup**: an alternative to full/incremental backups,
diff --git a/manual/en/050-quick-tour.mdwn b/manual/en/050-quick-tour.mdwn
index bf5ae92f..c84dd473 100644
--- a/manual/en/050-quick-tour.mdwn
+++ b/manual/en/050-quick-tour.mdwn
@@ -55,7 +55,7 @@ Multiple clients in one repository
You can backup multiple clients to a single repository by providing the
option --client-name=<identifier> when running the program. Backup sets
-will be kept separate, but data deduplication will happen across all
+will be kept separate, but data de-duplication will happen across all
the sets.
Removing old generations
diff --git a/manual/en/060-backing-up.mdwn b/manual/en/060-backing-up.mdwn
index e35efa8c..6d9e7dbf 100644
--- a/manual/en/060-backing-up.mdwn
+++ b/manual/en/060-backing-up.mdwn
@@ -33,7 +33,7 @@ This tells you that Obnam found a total of eleven files, of which it
backed up all eleven. The files contained a total of about a hundred
kilobytes of data, and that the upload speed for that data was over
six hundred kilobytes per second. The actual units are using IEC
-prefixes, which are base-2, for unambiguity. See
+prefixes, which are base-2, to avoid ambiguity. See
[Wikipedia on kibibytes] for more information.
[Wikipedia on kibibytes]: https://en.wikipedia.org/wiki/Kibibyte
@@ -95,7 +95,7 @@ multiple backup roots:
obnam -r /media/backups/tomjon-repo ~/Documents ~/Photos
-Everything in the backup root directories gets backedup -- unless it's
+Everything in the backup root directories gets backed up -- unless it's
explicitly excluded. There are several ways to exclude things from
backups:
@@ -103,7 +103,7 @@ backups:
pathname of each file or directory: if the pathname matches, the
file or directory is not backed up. In fact, Obnam pretends it
doesn't exist. If a directory matches, then any files and
- subdirectories also get excluded. This can be used, for example, to
+ sub-directories also get excluded. This can be used, for example, to
exclude all MP3 files (`--exclude='\.mp3$'`).
* The `--exclude-caches` setting excludes directories that contain a
special "cache tag" file called `CACHEDIR.TAG`, that starts with a
@@ -309,7 +309,7 @@ trampling on each other, they lock parts of the repository while
working. The "Sharing a repository between multiple clients" chapter
will discuss this in more detail.
-If Obnam terminates abruptly, even if there's only one evern client
+If Obnam terminates abruptly, even if there's only one client ever
using the repository, the lock may stay around and prevent that one
client for making new backups. The termination may be due to the
network connection breaking, or due to a bug in Obnam. It can also
@@ -376,7 +376,7 @@ doesn't let you sleep better.
Usually, though, most systems have enough idle time that a consistent
backup snapshot can happen during that time. For a laptop, for
-example, a backup can be run whlie the user is elsewhere, instead of
+example, a backup can be run while the user is elsewhere, instead of
actively using the machine.
Part of your backup verification suite should check that the data in a
@@ -384,5 +384,5 @@ backup generation is internally consistent, if that can be done.
Otherwise, you'll either have to analyse the applications you use, or
trust they're not too buggy.
-If you didn't underatand this section, don't worry and be happy and
+If you didn't understand this section, don't worry and be happy and
sleep well.
diff --git a/manual/en/070-restoring.mdwn b/manual/en/070-restoring.mdwn
index af2b7541..378b071e 100644
--- a/manual/en/070-restoring.mdwn
+++ b/manual/en/070-restoring.mdwn
@@ -65,7 +65,7 @@ repository:
fusermount -u ~/backups
In addition to doing these things from the command line, you can, of
-course, use your favorite file manager (graphical or textual) to look
+course, use your favourite file manager (graphical or textual) to look
at your backed up files. The mounting and un-mounting (depending on
your desktop setup) may need to be done on the command line.
diff --git a/manual/en/080-forgetting.mdwn b/manual/en/080-forgetting.mdwn
index 52d10a75..1df2ff64 100644
--- a/manual/en/080-forgetting.mdwn
+++ b/manual/en/080-forgetting.mdwn
@@ -64,7 +64,7 @@ space you're willing to spend on protecting against them.
spectacular way, such as by catching fire or being stolen? If so,
you really only need one very recent backup to cover against that.
* Do you worry about your hard drive, or filesystem, or your
- applicatin programs, or you yourself, slowly corrupting your data
+ application programs, or you yourself, slowly corrupting your data
over a longer period of time? How long will it take you to find that
out? You need a backup history that lasts longer than it takes for
you to detect slow corruption.
@@ -79,7 +79,7 @@ want to compare how things were each year in between. With increasing
storage space and nice de-duplication features, this isn't quite as
expensive as it might be.
-There is no one schedule that fits everyones needs and wants. You have
-to decide for youself. That's why the default in Obnam is to keep
+There is no one schedule that fits everyone's needs and wants. You have
+to decide for yourself. That's why the default in Obnam is to keep
everything forever. It's not Obnam's duty to decide that you should
not keep this or that backup generation.
diff --git a/manual/en/090-verifiying.mdwn b/manual/en/090-verifiying.mdwn
index 7bd2a2d9..a818d0d7 100644
--- a/manual/en/090-verifiying.mdwn
+++ b/manual/en/090-verifiying.mdwn
@@ -17,10 +17,10 @@ enough free disk space to restore everything, but it's almost the
only way to be really sure.
It's also a great way to ensure the restoring actually works. If
-you don't test that, don't expect it'll workd when needed.
+you don't test that, don't expect it'll work when needed.
If you have the disk space to do a complete restore, doing so is a
-great way to excercise your disaster recovery process in general.
+great way to exercise your disaster recovery process in general.
Here's one way of doing it:
* On your main computer, do a backup.
@@ -37,7 +37,7 @@ How often should you do that? That, again, depends on how you feel about
your data, and how much you trust your backup tools and processes. If
it's really important that you can recover from a disaster, you need to
verify more frequently. If data loss is merely inconvenient and not
-life-changingly disastrous, you can verify less often.
+disastrous in a life changing way, you can verify less often.
In addition to restoring data, Obnam provides two other ways to
verify your backups:
diff --git a/manual/en/110-encryption.mdwn b/manual/en/110-encryption.mdwn
index ecb36095..7601ea33 100644
--- a/manual/en/110-encryption.mdwn
+++ b/manual/en/110-encryption.mdwn
@@ -82,11 +82,11 @@ reading each others e-mail from the backup repository, for example,
but it does protect them against their parents, if the parents don't
have a suitable encryption key.
-In addition to the encryptions for client you can add additional keys.
-These keys can also access the backup repository. For example, the
-parents' key might be added to the repository so that if need be, they
-could restore any child's data, even if the child had lost their own
-encryption key.
+In addition to the encryption keys for a client you can add additional
+keys. These keys can also access the backup repository. For example,
+the parents' key might be added to the repository so that if need be,
+they could restore any child's data, even if the child had lost their
+own encryption key.
In a corporate setting, the a backup administrator key might be added
so that the administrator can, for example, verify the integrity of
diff --git a/manual/en/150-config.mdwn b/manual/en/150-config.mdwn
index 99d92ca1..a62cfc3e 100644
--- a/manual/en/150-config.mdwn
+++ b/manual/en/150-config.mdwn
@@ -81,7 +81,7 @@ exceptions to this are:
* Boolean or yes/no or on/off settings. For example,
`--exclude-caches` is a setting that is either turned on (when the
- option is used) or off (when it's not used). For every boolean
+ option is used) or off (when it's not used). For every Boolean
setting `--foo`, there is an option `--no-foo`. In a configuration
files, `foo` is turned on by setting it to `yes` or `true`, and off
by setting it to `no` or `false`.