build_usage

docs/usage/check.rst.inc

@@ -86,44 +86,41 @@ The check command verifies the consistency of a repository and the corresponding
 
 First, the underlying repository data files are checked:
 
-- For all segments the segment magic (header) is checked
-- For all objects stored in the segments, all metadata (e.g. crc and size) and
+- For all segments, the segment magic header is checked.
+- For all objects stored in the segments, all metadata (e.g. CRC and size) and
   all data is read. The read data is checked by size and CRC. Bit rot and other
   types of accidental damage can be detected this way.
-- If we are in repair mode and a integrity error is detected for a segment,
-  we try to recover as many objects from the segment as possible.
-- In repair mode, it makes sure that the index is consistent with the data
-  stored in the segments.
-- If you use a remote repo server via ssh:, the repo check is executed on the
-  repo server without causing significant network traffic.
+- In repair mode, if an integrity error is detected in a segment, try to recover
+  as many objects from the segment as possible.
+- In repair mode, make sure that the index is consistent with the data stored in
+  the segments.
+- If checking a remote repo via ``ssh:``, the repo check is executed on the server
+  without causing significant network traffic.
 - The repository check can be skipped using the ``--archives-only`` option.
 
 Second, the consistency and correctness of the archive metadata is verified:
 
 - Is the repo manifest present? If not, it is rebuilt from archive metadata
   chunks (this requires reading and decrypting of all metadata and data).
-- Check if archive metadata chunk is present. if not, remove archive from
-  manifest.
+- Check if archive metadata chunk is present; if not, remove archive from manifest.
 - For all files (items) in the archive, for all chunks referenced by these
-  files, check if chunk is present.
-  If a chunk is not present and we are in repair mode, replace it with a same-size
-  replacement chunk of zeros.
-  If a previously lost chunk reappears (e.g. via a later backup) and we are in
-  repair mode, the all-zero replacement chunk will be replaced by the correct chunk.
-  This requires reading of archive and file metadata, but not data.
-- If we are in repair mode and we checked all the archives: delete orphaned
-  chunks from the repo.
-- if you use a remote repo server via ssh:, the archive check is executed on
-  the client machine (because if encryption is enabled, the checks will require
-  decryption and this is always done client-side, because key access will be
-  required).
-- The archive checks can be time consuming, they can be skipped using the
+  files, check if chunk is present. In repair mode, if a chunk is not present,
+  replace it with a same-size replacement chunk of zeroes. If a previously lost
+  chunk reappears (e.g. via a later backup), in repair mode the all-zero replacement
+  chunk will be replaced by the correct chunk. This requires reading of archive and
+  file metadata, but not data.
+- In repair mode, when all the archives were checked, orphaned chunks are deleted
+  from the repo. One cause of orphaned chunks are input file related errors (like
+  read errors) in the archive creation process.
+- If checking a remote repo via ``ssh:``, the archive check is executed on the
+  client machine because it requires decryption, and this is always done client-side
+  as key access is needed.
+- The archive checks can be time consuming; they can be skipped using the
   ``--repository-only`` option.
 
 The ``--verify-data`` option will perform a full integrity verification (as opposed to
 checking the CRC32 of the segment) of data, which means reading the data from the
 repository, decrypting and decompressing it. This is a cryptographic verification,
 which will detect (accidental) corruption. For encrypted repositories it is
-tamper-resistant as well, unless the attacker has access to the keys.
-
-It is also very slow.
+tamper-resistant as well, unless the attacker has access to the keys. It is also very
+slow.

docs/usage/common-options.rst.inc

@@ -8,6 +8,7 @@
 -p, --progress     show progress information
 --log-json         Output one JSON object per log line instead of formatted text.
 --lock-wait SECONDS    wait at most SECONDS for acquiring a repository/cache lock (default: 1).
+--bypass-lock      Bypass locking mechanism
 --show-version     show/log the borg version
 --show-rc          show/log the return code (rc)
 --umask M          set umask to M (local and remote, default: 0077)

docs/usage/help.rst.inc

@@ -11,17 +11,26 @@ currently active recursion root. You usually give the recursion root(s)
 when invoking borg and these can be either relative or absolute paths.
 
 So, when you give `relative/` as root, the paths going into the matcher
-will look like `relative/.../file.ext`. When you give `/absolute/` as root,
-they will look like `/absolute/.../file.ext`. This is meant when we talk
-about "full path" below.
+will look like `relative/.../file.ext`. When you give `/absolute/` as
+root, they will look like `/absolute/.../file.ext`. This is meant when
+we talk about "full path" below.
+
+File paths in Borg archives are always stored normalized and relative.
+This means that e.g. ``borg create /path/to/repo ../some/path`` will
+store all files as `some/path/.../file.ext` and ``borg create
+/path/to/repo /home/user`` will store all files as
+`home/user/.../file.ext`. Therefore, always use relative paths in your
+patterns when matching archive content in commands like ``extract`` or
+``mount``. Starting with Borg 1.2 this behaviour will be changed to
+accept both absolute and relative paths.
 
 File patterns support these styles: fnmatch, shell, regular expressions,
 path prefixes and path full-matches. By default, fnmatch is used for
-``--exclude`` patterns and shell-style is used for the experimental ``--pattern``
-option.
+``--exclude`` patterns and shell-style is used for the experimental
+``--pattern`` option.
 
-If followed by a colon (':') the first two characters of a pattern are used as a
-style selector. Explicit style selection is necessary when a
+If followed by a colon (':') the first two characters of a pattern are
+used as a style selector. Explicit style selection is necessary when a
 non-default style is desired or when the desired pattern starts with
 two alphanumeric characters followed by a colon (i.e. `aa:something/*`).
 

docs/usage/init.rst.inc

@@ -67,7 +67,11 @@ Encryption can be enabled at repository init time. It cannot be changed later.
 It is not recommended to work without encryption. Repository encryption protects
 you e.g. against the case that an attacker has access to your backup repository.
 
-But be careful with the key / the passphrase:
+Borg relies on randomly generated key material and uses that for chunking, id
+generation, encryption and authentication. The key material is encrypted using
+the passphrase you give before it is stored on-disk.
+
+You need to be careful with the key / the passphrase:
 
 If you want "passphrase-only" security, use one of the repokey modes. The
 key will be stored inside the repository (in its "config" file). In above
@@ -105,6 +109,12 @@ the encryption/decryption key or other secrets.
 Encryption modes
 ++++++++++++++++
 
+You can choose from the encryption modes seen in the table below on a per-repo
+basis. The mode determines encryption algorithm, hash/MAC algorithm and also the
+key storage location.
+
+Example: `borg init --encryption repokey ...`
+
 .. nanorst: inline-fill
 
 +----------+---------------+------------------------+--------------------------+
@@ -120,7 +130,8 @@ Encryption modes
 
 .. nanorst: inline-replace
 
-`Marked modes` are new in Borg 1.1 and are not backwards-compatible with Borg 1.0.x.
+Modes `marked like this` in the above table are new in Borg 1.1 and are not
+backwards-compatible with Borg 1.0.x.
 
 On modern Intel/AMD CPUs (except very cheap ones), AES is usually
 hardware-accelerated.
@@ -153,8 +164,8 @@ from the other blake2 modes.
 This mode is new and *not* compatible with Borg 1.0.x.
 
 `none` mode uses no encryption and no authentication. It uses SHA256 as chunk
-ID hash. Not recommended, rather consider using an authenticated or
-authenticated/encrypted mode. This mode has possible denial-of-service issues
+ID hash. This mode is not recommended, you should rather consider using an authenticated
+or authenticated/encrypted mode. This mode has possible denial-of-service issues
 when running ``borg create`` on contents controlled by an attacker.
 Use it only for new repositories where no encryption is wanted **and** when compatibility
 with 1.0.x is important. If compatibility with 1.0.x is not important, use