upgrade.rst.inc 3.9 KB

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