check.rst.inc 16 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199
  1. .. IMPORTANT: this file is auto-generated from borg's built-in help, do not edit!
  2. .. _borg_check:
  3. borg check
  4. ----------
  5. .. code-block:: none
  6. borg [common options] check [options]
  7. .. only:: html
  8. .. class:: borg-options-table
  9. +-----------------------------------------------------------------------------+----------------------------------------------+---------------------------------------------------------------------------------------------------+
  10. | **options** |
  11. +-----------------------------------------------------------------------------+----------------------------------------------+---------------------------------------------------------------------------------------------------+
  12. | | ``--repository-only`` | only perform repository checks |
  13. +-----------------------------------------------------------------------------+----------------------------------------------+---------------------------------------------------------------------------------------------------+
  14. | | ``--archives-only`` | only perform archives checks |
  15. +-----------------------------------------------------------------------------+----------------------------------------------+---------------------------------------------------------------------------------------------------+
  16. | | ``--verify-data`` | perform cryptographic archive data integrity verification (conflicts with ``--repository-only``) |
  17. +-----------------------------------------------------------------------------+----------------------------------------------+---------------------------------------------------------------------------------------------------+
  18. | | ``--repair`` | attempt to repair any inconsistencies found |
  19. +-----------------------------------------------------------------------------+----------------------------------------------+---------------------------------------------------------------------------------------------------+
  20. | | ``--max-duration SECONDS`` | do only a partial repo check for max. SECONDS seconds (Default: unlimited) |
  21. +-----------------------------------------------------------------------------+----------------------------------------------+---------------------------------------------------------------------------------------------------+
  22. | .. class:: borg-common-opt-ref |
  23. | |
  24. | :ref:`common_options` |
  25. +-----------------------------------------------------------------------------+----------------------------------------------+---------------------------------------------------------------------------------------------------+
  26. | **Archive filters** — Archive filters can be applied to repository targets. |
  27. +-----------------------------------------------------------------------------+----------------------------------------------+---------------------------------------------------------------------------------------------------+
  28. | | ``-a PATTERN``, ``--match-archives PATTERN`` | only consider archive names matching the pattern. see "borg help match-archives". |
  29. +-----------------------------------------------------------------------------+----------------------------------------------+---------------------------------------------------------------------------------------------------+
  30. | | ``--sort-by KEYS`` | Comma-separated list of sorting keys; valid keys are: timestamp, name, id; default is: timestamp |
  31. +-----------------------------------------------------------------------------+----------------------------------------------+---------------------------------------------------------------------------------------------------+
  32. | | ``--first N`` | consider first N archives after other filters were applied |
  33. +-----------------------------------------------------------------------------+----------------------------------------------+---------------------------------------------------------------------------------------------------+
  34. | | ``--last N`` | consider last N archives after other filters were applied |
  35. +-----------------------------------------------------------------------------+----------------------------------------------+---------------------------------------------------------------------------------------------------+
  36. | | ``--oldest TIMESPAN`` | consider archives between the oldest archive's timestamp and (oldest + TIMESPAN), e.g. 7d or 12m. |
  37. +-----------------------------------------------------------------------------+----------------------------------------------+---------------------------------------------------------------------------------------------------+
  38. | | ``--newest TIMESPAN`` | consider archives between the newest archive's timestamp and (newest - TIMESPAN), e.g. 7d or 12m. |
  39. +-----------------------------------------------------------------------------+----------------------------------------------+---------------------------------------------------------------------------------------------------+
  40. | | ``--older TIMESPAN`` | consider archives older than (now - TIMESPAN), e.g. 7d oder 12m. |
  41. +-----------------------------------------------------------------------------+----------------------------------------------+---------------------------------------------------------------------------------------------------+
  42. | | ``--newer TIMESPAN`` | consider archives newer than (now - TIMESPAN), e.g. 7d or 12m. |
  43. +-----------------------------------------------------------------------------+----------------------------------------------+---------------------------------------------------------------------------------------------------+
  44. .. raw:: html
  45. <script type='text/javascript'>
  46. $(document).ready(function () {
  47. $('.borg-options-table colgroup').remove();
  48. })
  49. </script>
  50. .. only:: latex
  51. options
  52. --repository-only only perform repository checks
  53. --archives-only only perform archives checks
  54. --verify-data perform cryptographic archive data integrity verification (conflicts with ``--repository-only``)
  55. --repair attempt to repair any inconsistencies found
  56. --max-duration SECONDS do only a partial repo check for max. SECONDS seconds (Default: unlimited)
  57. :ref:`common_options`
  58. |
  59. Archive filters
  60. -a PATTERN, --match-archives PATTERN only consider archive names matching the pattern. see "borg help match-archives".
  61. --sort-by KEYS Comma-separated list of sorting keys; valid keys are: timestamp, name, id; default is: timestamp
  62. --first N consider first N archives after other filters were applied
  63. --last N consider last N archives after other filters were applied
  64. --oldest TIMESPAN consider archives between the oldest archive's timestamp and (oldest + TIMESPAN), e.g. 7d or 12m.
  65. --newest TIMESPAN consider archives between the newest archive's timestamp and (newest - TIMESPAN), e.g. 7d or 12m.
  66. --older TIMESPAN consider archives older than (now - TIMESPAN), e.g. 7d oder 12m.
  67. --newer TIMESPAN consider archives newer than (now - TIMESPAN), e.g. 7d or 12m.
  68. Description
  69. ~~~~~~~~~~~
  70. The check command verifies the consistency of a repository and its archives.
  71. It consists of two major steps:
  72. 1. Checking the consistency of the repository itself. This includes checking
  73. the segment magic headers, and both the metadata and data of all objects in
  74. the segments. The read data is checked by size and CRC. Bit rot and other
  75. types of accidental damage can be detected this way. Running the repository
  76. check can be split into multiple partial checks using ``--max-duration``.
  77. When checking a remote repository, please note that the checks run on the
  78. server and do not cause significant network traffic.
  79. 2. Checking consistency and correctness of the archive metadata and optionally
  80. archive data (requires ``--verify-data``). This includes ensuring that the
  81. repository manifest exists, the archive metadata chunk is present, and that
  82. all chunks referencing files (items) in the archive exist. This requires
  83. reading archive and file metadata, but not data. To cryptographically verify
  84. the file (content) data integrity pass ``--verify-data``, but keep in mind
  85. that this requires reading all data and is hence very time consuming. When
  86. checking archives of a remote repository, archive checks run on the client
  87. machine because they require decrypting data and therefore the encryption
  88. key.
  89. Both steps can also be run independently. Pass ``--repository-only`` to run the
  90. repository checks only, or pass ``--archives-only`` to run the archive checks
  91. only.
  92. The ``--max-duration`` option can be used to split a long-running repository
  93. check into multiple partial checks. After the given number of seconds the check
  94. is interrupted. The next partial check will continue where the previous one
  95. stopped, until the full repository has been checked. Assuming a complete check
  96. would take 7 hours, then running a daily check with ``--max-duration=3600``
  97. (1 hour) would result in one full repository check per week. Doing a full
  98. repository check aborts any previous partial check; the next partial check will
  99. restart from the beginning. With partial repository checks you can run neither
  100. archive checks, nor enable repair mode. Consequently, if you want to use
  101. ``--max-duration`` you must also pass ``--repository-only``, and must not pass
  102. ``--archives-only``, nor ``--repair``.
  103. **Warning:** Please note that partial repository checks (i.e. running it with
  104. ``--max-duration``) can only perform non-cryptographic checksum checks on the
  105. segment files. A full repository check (i.e. without ``--max-duration``) can
  106. also do a repository index check. Enabling partial repository checks excepts
  107. archive checks for the same reason. Therefore partial checks may be useful with
  108. very large repositories only where a full check would take too long.
  109. The ``--verify-data`` option will perform a full integrity verification (as
  110. opposed to checking the CRC32 of the segment) of data, which means reading the
  111. data from the repository, decrypting and decompressing it. It is a complete
  112. cryptographic verification and hence very time consuming, but will detect any
  113. accidental and malicious corruption. Tamper-resistance is only guaranteed for
  114. encrypted repositories against attackers without access to the keys. You can
  115. not use ``--verify-data`` with ``--repository-only``.
  116. About repair mode
  117. +++++++++++++++++
  118. The check command is a readonly task by default. If any corruption is found,
  119. Borg will report the issue and proceed with checking. To actually repair the
  120. issues found, pass ``--repair``.
  121. .. note::
  122. ``--repair`` is a **POTENTIALLY DANGEROUS FEATURE** and might lead to data
  123. loss! This does not just include data that was previously lost anyway, but
  124. might include more data for kinds of corruption it is not capable of
  125. dealing with. **BE VERY CAREFUL!**
  126. Pursuant to the previous warning it is also highly recommended to test the
  127. reliability of the hardware running Borg with stress testing software. This
  128. especially includes storage and memory testers. Unreliable hardware might lead
  129. to additional data loss.
  130. It is highly recommended to create a backup of your repository before running
  131. in repair mode (i.e. running it with ``--repair``).
  132. Repair mode will attempt to fix any corruptions found. Fixing corruptions does
  133. not mean recovering lost data: Borg can not magically restore data lost due to
  134. e.g. a hardware failure. Repairing a repository means sacrificing some data
  135. for the sake of the repository as a whole and the remaining data. Hence it is,
  136. by definition, a potentially lossy task.
  137. In practice, repair mode hooks into both the repository and archive checks:
  138. 1. When checking the repository's consistency, repair mode will try to recover
  139. as many objects from segments with integrity errors as possible, and ensure
  140. that the index is consistent with the data stored in the segments.
  141. 2. When checking the consistency and correctness of archives, repair mode might
  142. remove whole archives from the manifest if their archive metadata chunk is
  143. corrupt or lost. On a chunk level (i.e. the contents of files), repair mode
  144. will replace corrupt or lost chunks with a same-size replacement chunk of
  145. zeroes. If a previously zeroed chunk reappears, repair mode will restore
  146. this lost chunk using the new chunk. Lastly, repair mode will also delete
  147. orphaned chunks (e.g. caused by read errors while creating the archive).
  148. Most steps taken by repair mode have a one-time effect on the repository, like
  149. removing a lost archive from the repository. However, replacing a corrupt or
  150. lost chunk with an all-zero replacement will have an ongoing effect on the
  151. repository: When attempting to extract a file referencing an all-zero chunk,
  152. the ``extract`` command will distinctly warn about it. The FUSE filesystem
  153. created by the ``mount`` command will reject reading such a "zero-patched"
  154. file unless a special mount option is given.
  155. As mentioned earlier, Borg might be able to "heal" a "zero-patched" file in
  156. repair mode, if all its previously lost chunks reappear (e.g. via a later
  157. backup). This is achieved by Borg not only keeping track of the all-zero
  158. replacement chunks, but also by keeping metadata about the lost chunks. In
  159. repair mode Borg will check whether a previously lost chunk reappeared and will
  160. replace the all-zero replacement chunk by the reappeared chunk. If all lost
  161. chunks of a "zero-patched" file reappear, this effectively "heals" the file.
  162. Consequently, if lost chunks were repaired earlier, it is advised to run
  163. ``--repair`` a second time after creating some new backups.