init.rst.inc 18 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272
  1. .. IMPORTANT: this file is auto-generated from borg's built-in help, do not edit!
  2. .. _borg_init:
  3. borg init
  4. ---------
  5. .. code-block:: none
  6. borg [common options] init [options] [REPOSITORY]
  7. .. only:: html
  8. .. class:: borg-options-table
  9. +-------------------------------------------------------+------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
  10. | **positional arguments** |
  11. +-------------------------------------------------------+------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
  12. | | ``REPOSITORY`` | repository to create |
  13. +-------------------------------------------------------+------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
  14. | **options** |
  15. +-------------------------------------------------------+------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
  16. | | ``-e MODE``, ``--encryption MODE`` | select encryption key mode **(required)** |
  17. +-------------------------------------------------------+------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
  18. | | ``--append-only`` | create an append-only mode repository. Note that this only affects the low level structure of the repository, and running `delete` or `prune` will still be allowed. See :ref:`append_only_mode` in Additional Notes for more details. |
  19. +-------------------------------------------------------+------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
  20. | | ``--storage-quota QUOTA`` | Set storage quota of the new repository (e.g. 5G, 1.5T). Default: no quota. |
  21. +-------------------------------------------------------+------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
  22. | | ``--make-parent-dirs`` | create the parent directories of the repository directory, if they are missing. |
  23. +-------------------------------------------------------+------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
  24. | .. class:: borg-common-opt-ref |
  25. | |
  26. | :ref:`common_options` |
  27. +-------------------------------------------------------+------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
  28. .. raw:: html
  29. <script type='text/javascript'>
  30. $(document).ready(function () {
  31. $('.borg-options-table colgroup').remove();
  32. })
  33. </script>
  34. .. only:: latex
  35. REPOSITORY
  36. repository to create
  37. options
  38. -e MODE, --encryption MODE select encryption key mode **(required)**
  39. --append-only create an append-only mode repository. Note that this only affects the low level structure of the repository, and running `delete` or `prune` will still be allowed. See :ref:`append_only_mode` in Additional Notes for more details.
  40. --storage-quota QUOTA Set storage quota of the new repository (e.g. 5G, 1.5T). Default: no quota.
  41. --make-parent-dirs create the parent directories of the repository directory, if they are missing.
  42. :ref:`common_options`
  43. |
  44. Description
  45. ~~~~~~~~~~~
  46. This command initializes an empty repository. A repository is a
  47. filesystem directory containing the deduplicated data from zero or more
  48. archives.
  49. Encryption mode TL;DR
  50. +++++++++++++++++++++
  51. The encryption mode can only be configured when creating a new
  52. repository. You can neither configure encryption on a per-archive
  53. basis, nor change the encryption mode of an existing repository. You
  54. should thus take possible future use into account when deciding on an
  55. encryption mode.
  56. As a general rule of thumb, use ``repokey`` with a strong passphrase:
  57. borg init --encryption repokey /path/to/repo
  58. However, there are many reasons to choose differently. See the section
  59. below for details. In any case, Borg will:
  60. 1. Ask you to enter a unique and strong passphrase.
  61. 2. Create a random Borg key (which actually consists of three random
  62. secrets, see :ref:`key_files` for details).
  63. 3. Encrypt the Borg key with your passphrase.
  64. 4. Store the encrypted Borg key inside the repository directory (with
  65. ``repokey`` and ``repokey-blake2`` modes; with ``keyfile`` and
  66. ``keyfile-blake2`` modes the Borg key is stored in your home
  67. directory instead, see below). Since we usually have to assume that
  68. an attacker could gain access to the repository (that's why we
  69. encrypt the data in the first place), choosing a strong and unique
  70. passphrase is absolutely crucial.
  71. 5. Encrypt and sign your backups with the Borg key to prevent anyone
  72. from reading or forging them unless they have the Borg key *and*
  73. know the passphrase.
  74. 6. Use the Borg key to decrypt and thus access the data stored in your
  75. repository, e.g. when extracting files. The contents can also be
  76. verified to detect accidental corruption or malicious tampering.
  77. As you can see, you always need *both* the Borg key and passphrase to
  78. access your data. Thus it's crucial to keep a backup of your key
  79. *outside* both the repository and the system you create backups of.
  80. You can easily run into a "leaving your keys inside your car" situation
  81. otherwise. See :ref:`borg_key_export` to create a backup of your key
  82. (e.g., by printing it on paper).
  83. Encryption is done locally - i.e., if you back up to a remote machine,
  84. the remote machine neither sees your passphrase, nor your unencrypted
  85. Borg key, nor your unencrypted files. Chunking and ID generation are
  86. based on your key to improve privacy.
  87. **About hardware acceleration:**
  88. Borg encrypts data with AES, which is pretty fast thanks to hardware
  89. acceleration on basically all modern Intel, AMD, and ARM CPUs since
  90. around the early 2010s (very cheap models since the mid-2010s).
  91. As the hashing algorithm, Borg can use either SHA256 or BLAKE2b. ARM
  92. CPUs support hardware-accelerated SHA256 hashing since ARMv7 with NEON
  93. (around 2011), or ARMv8 (around 2013). AMD CPUs support it since Zen 1
  94. (around 2017), i.e. all AMD Ryzen CPUs. Intel CPUs support it since Ice
  95. Lake on mobile (10th gen, around 2021), and Rocket Lake on desktop
  96. (11th gen, around 2021). Very cheap models have received support a few
  97. years later. If your CPU doesn't support hardware-accelerated SHA256
  98. hashing, you might want to give BLAKE2b hashing a try - it's likely
  99. faster then. So, instead of ``repokey`` mode, use ``repokey-blake2``
  100. (or any of the other ``-blake2`` modes for that matter).
  101. Hardware acceleration is always used automatically when available.
  102. Picking a passphrase
  103. ++++++++++++++++++++
  104. Make sure you use a good passphrase. Not too short, not too simple. The
  105. real encryption / decryption key is encrypted with / locked by your
  106. passphrase. If an attacker gets your borg key, they can't unlock and use
  107. it without knowing the passphrase.
  108. Be careful with special or non-ASCII characters in your passphrase:
  109. - Borg processes the passphrase as Unicode (and encodes it as UTF-8), so
  110. it does not have problems dealing with even the strangest characters.
  111. - BUT: that does not necessarily apply to your OS / VM / keyboard
  112. configuration.
  113. So it is better to use a long passphrase made from simple ASCII
  114. characters than one that includes non-ASCII characters or characters
  115. that are hard or impossible to enter on a different keyboard layout.
  116. You can change your passphrase for existing repositories at any time; it
  117. won't affect the encryption/decryption key or other secrets. See
  118. :ref:`borg_key_change-passphrase`.
  119. More about encryption modes
  120. +++++++++++++++++++++++++++
  121. Choosing the right encryption mode isn't always easy and many factors
  122. can change which mode is best for you. However, note that you can't
  123. really do anything *wrong* if you choose ``repokey`` with a strong
  124. passphrase. So, if you're not sure, choose ``repokey`` (or
  125. ``repokey-blake2``, depending on your hardware, see above).
  126. Borg supports the following encryption modes:
  127. .. nanorst: inline-fill
  128. .. class:: borg-encryption-table
  129. +----------+-------------------+--------------------------+-------------------------+
  130. | Hash/MAC | Not Encrypted | Encrypted (AEAD w/ AES) |
  131. + +-------------------+--------------------------+-------------------------+
  132. | | Not Authenticated | Authenticated |
  133. +==========+===================+==========================+=========================+
  134. | SHA-256 | ``none`` | ``authenticated`` | ``repokey`` |
  135. | | | | ``keyfile`` |
  136. +----------+-------------------+--------------------------+-------------------------+
  137. | BLAKE2b | n/a | ``authenticated-blake2`` | ``repokey-blake2`` |
  138. | | | | ``keyfile-blake2`` |
  139. +----------+-------------------+--------------------------+-------------------------+
  140. .. nanorst: inline-replace
  141. Borg 1.0 and older support ``none``, ``repokey``, and ``keyfile``
  142. modes only. If you need such old clients to be able to access your
  143. repo, you can't use any of the other modes.
  144. **About modes without encryption:**
  145. Avoid using ``none`` mode. If you think about using ``none`` mode,
  146. please reconsider and be absolutely sure. Using any mode other than
  147. ``none`` allows Borg to detect accidental corruption or malicious
  148. tampering with the repo. It also prevents denial-of-service attacks
  149. against clients. Instead of ``none`` mode, you likely want to use
  150. ``authenticated`` mode, or ``repokey`` or ``keyfile`` modes with an
  151. empty passphrase instead (see below).
  152. If you don't want to encrypt your data, use ``authenticated`` or
  153. ``authenticated-blake2`` modes. These modes require a passphrase in
  154. normal operation, but in emergency situations you can access the repo
  155. without the passphrase with ``BORG_WORKAROUNDS=authenticated_no_key``
  156. (see :ref:`environment-variables`).
  157. If you just don't want to choose a passphrase, use ``keyfile`` or
  158. ``keyfile-blake2`` modes with an empty passphrase. These modes are
  159. generally safe even without a passphrase, but keeping an offsite
  160. backup of the Borg key is also important then. See below for details.
  161. If you can assure that an attacker can't gain access to your repo, e.g.
  162. when independently encrypting your repository disk or filesystem, you
  163. can think about using ``repokey`` or ``repokey-blake2`` modes with an
  164. empty passphrase. However, keep in mind that if an attacker still
  165. somehow manages to gain access, they have full access to your repo. In
  166. such situations choosing ``repokey`` over ``authenticated`` mode has
  167. the advantage of allowing you to add a passphrase later using
  168. :ref:`borg_key_change-passphrase`.
  169. **About modes with encryption:**
  170. With ``repokey`` and ``repokey-blake2`` modes the key is stored with
  171. the repo and encrypted with your passphrase. If an attacker gains
  172. access to your repo and knows the passphrase, he can access and tamper
  173. with the repo. The repo's security thus relies on the strength of your
  174. passphrase. Creating an offsite backup of your Borg key (e.g., by
  175. printing it on paper) is recommended, see :ref:`borg_key_export`.
  176. If you're thinking about storing the passphrase on the disk of the
  177. system you're backing up, consider using the ``keyfile`` method
  178. instead. It generally provides the same or better security then.
  179. With ``keyfile`` and ``keyfile-blake2`` modes the key is stored on your
  180. local machine (in ``~/.config/borg/keys``) instead. An attacker gaining
  181. access to your repo then needs both the Borg key, and your passphrase to
  182. access and tamper with the repo. However, if you lose the key, you lose
  183. access to the repo, too. You **must** create an offsite backup of your
  184. Borg key, e.g. by printing it on paper. Storing a copy of the Borg key
  185. on the system you're creating backups of is **NOT** sufficient. Use
  186. :ref:`borg_key_export` to create the backup.
  187. The ``keyfile`` and ``keyfile-blake2`` modes allow for "passphrase and
  188. having-the-key" security when using a strong passphrase, but can also
  189. be used with an empty passphrase. Storing a (easily readable)
  190. passphrase on the disk of the system you're backing up with
  191. ``keyfile`` and ``keyfile-blake2`` modes adds no security over using an
  192. empty passphrase.
  193. **Technical details:**
  194. ``repokey`` and ``keyfile`` use AES-CTR-256 for encryption and
  195. HMAC-SHA256 for authentication in an encrypt-then-MAC (EtM)
  196. construction. The chunk ID hash is HMAC-SHA256 (with a separate key).
  197. These modes are compatible with all Borg versions.
  198. ``repokey-blake2`` and ``keyfile-blake2`` are also authenticated
  199. encryption modes, but use BLAKE2b-256 instead of HMAC-SHA256 for
  200. authentication. The chunk ID hash is a keyed BLAKE2b-256 hash. These
  201. modes are only compatible with Borg 1.1 and later.
  202. ``authenticated`` mode uses no encryption, but authenticates repo
  203. contents through the same HMAC-SHA256 hash as the ``repokey`` and
  204. ``keyfile`` modes (it uses it as the chunk ID hash). The key is stored
  205. like ``repokey`` within the repo. This mode is only compatible with
  206. Borg 1.1 and later.
  207. ``authenticated-blake2`` is like ``authenticated``, but uses the keyed
  208. BLAKE2b-256 hash from the other BLAKE2b modes. This mode is only
  209. compatible with Borg 1.1 and later.
  210. ``none`` mode uses no encryption and no authentication. It uses SHA256
  211. as chunk ID hash. This mode is not recommended. You should instead
  212. consider using an authenticated or authenticated/encrypted mode. This
  213. mode has possible denial-of-service issues when running ``borg create``
  214. on contents controlled by an attacker. See above for alternatives.
  215. This mode is compatible with all Borg versions.