upgrade.rst.inc 4.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116
  1. .. IMPORTANT: this file is auto-generated from borg's built-in help, do not edit!
  2. .. _borg_upgrade:
  3. borg upgrade
  4. ------------
  5. ::
  6. borg upgrade <options> REPOSITORY
  7. positional arguments
  8. REPOSITORY
  9. path to the repository to be upgraded
  10. optional arguments
  11. ``-p``, ``--progress``
  12. | show progress display while upgrading the repository
  13. ``-n``, ``--dry-run``
  14. | do not change repository
  15. ``-i``, ``--inplace``
  16. | rewrite repository in place, with no chance of going back to older
  17. | versions of the repository.
  18. ``--force``
  19. | Force upgrade
  20. ``--tam``
  21. | Enable manifest authentication (in key and cache) (Borg 1.0.9 and later)
  22. ``--disable-tam``
  23. | Disable manifest authentication (in key and cache)
  24. `Common options`_
  25. |
  26. Description
  27. ~~~~~~~~~~~
  28. Upgrade an existing, local Borg repository.
  29. When you do not need borg upgrade
  30. +++++++++++++++++++++++++++++++++
  31. Not every change requires that you run ``borg upgrade``.
  32. You do **not** need to run it when:
  33. - moving your repository to a different place
  34. - upgrading to another point release (like 1.0.x to 1.0.y),
  35. except when noted otherwise in the changelog
  36. - upgrading from 1.0.x to 1.1.x,
  37. except when noted otherwise in the changelog
  38. Borg 1.x.y upgrades
  39. +++++++++++++++++++
  40. Use ``borg upgrade --tam REPO`` to require manifest authentication
  41. introduced with Borg 1.0.9 to address security issues. This means
  42. that modifying the repository after doing this with a version prior
  43. to 1.0.9 will raise a validation error, so only perform this upgrade
  44. after updating all clients using the repository to 1.0.9 or newer.
  45. This upgrade should be done on each client for safety reasons.
  46. If a repository is accidentally modified with a pre-1.0.9 client after
  47. this upgrade, use ``borg upgrade --tam --force REPO`` to remedy it.
  48. If you routinely do this you might not want to enable this upgrade
  49. (which will leave you exposed to the security issue). You can
  50. reverse the upgrade by issuing ``borg upgrade --disable-tam REPO``.
  51. See
  52. https://borgbackup.readthedocs.io/en/stable/changes.html#pre-1-0-9-manifest-spoofing-vulnerability
  53. for details.
  54. Attic and Borg 0.xx to Borg 1.x
  55. +++++++++++++++++++++++++++++++
  56. This currently supports converting an Attic repository to Borg and also
  57. helps with converting Borg 0.xx to 1.0.
  58. Currently, only LOCAL repositories can be upgraded (issue #465).
  59. Please note that ``borg create`` (since 1.0.0) uses bigger chunks by
  60. default than old borg or attic did, so the new chunks won't deduplicate
  61. with the old chunks in the upgraded repository.
  62. See ``--chunker-params`` option of ``borg create`` and ``borg recreate``.
  63. ``borg upgrade`` will change the magic strings in the repository's
  64. segments to match the new Borg magic strings. The keyfiles found in
  65. $ATTIC_KEYS_DIR or ~/.attic/keys/ will also be converted and
  66. copied to $BORG_KEYS_DIR or ~/.config/borg/keys.
  67. The cache files are converted, from $ATTIC_CACHE_DIR or
  68. ~/.cache/attic to $BORG_CACHE_DIR or ~/.cache/borg, but the
  69. cache layout between Borg and Attic changed, so it is possible
  70. the first backup after the conversion takes longer than expected
  71. due to the cache resync.
  72. Upgrade should be able to resume if interrupted, although it
  73. will still iterate over all segments. If you want to start
  74. from scratch, use `borg delete` over the copied repository to
  75. make sure the cache files are also removed:
  76. borg delete borg
  77. Unless ``--inplace`` is specified, the upgrade process first
  78. creates a backup copy of the repository, in
  79. REPOSITORY.upgrade-DATETIME, using hardlinks. This takes
  80. longer than in place upgrades, but is much safer and gives
  81. progress information (as opposed to ``cp -al``). Once you are
  82. satisfied with the conversion, you can safely destroy the
  83. backup copy.
  84. WARNING: Running the upgrade in place will make the current
  85. copy unusable with older version, with no way of going back
  86. to previous versions. This can PERMANENTLY DAMAGE YOUR
  87. REPOSITORY! Attic CAN NOT READ BORG REPOSITORIES, as the
  88. magic strings have changed. You have been warned.