mirror of
https://github.com/borgbackup/borg.git
synced 2025-03-04 02:28:34 +00:00
docs: Borg documentation downplays severity of Nonce reuse issue, fixes #4883
This commit is contained in:
parent
54df299604
commit
25ab198d41
3 changed files with 19 additions and 8 deletions
13
docs/faq.rst
13
docs/faq.rst
|
@ -27,7 +27,12 @@ which is slower.
|
|||
Can I backup from multiple servers into a single repository?
|
||||
------------------------------------------------------------
|
||||
|
||||
Yes, but in order for the deduplication used by Borg to work, it
|
||||
Yes, this is *possible* from the technical standpoint, but it is
|
||||
*not recommended* from the security perspective. BorgBackup is
|
||||
built upon a defined :ref:`attack_model` that cannot provide its
|
||||
guarantees for multiple clients using the same repository.
|
||||
|
||||
Also, in order for the deduplication used by Borg to work, it
|
||||
needs to keep a local cache containing checksums of all file
|
||||
chunks already stored in the repository. This cache is stored in
|
||||
``~/.cache/borg/``. If Borg detects that a repository has been
|
||||
|
@ -85,9 +90,7 @@ Also, you must not run borg against multiple instances of the same repo
|
|||
- Encryption security issues if you would update repo and copy-of-repo
|
||||
independently, due to AES counter reuse.
|
||||
|
||||
There is also a similar encryption security issue for the disaster case:
|
||||
If you lose repo and the borg client-side config/cache and you restore
|
||||
the repo from an older copy-of-repo, you also run into AES counter reuse.
|
||||
See also: :ref:`faq_corrupt_repo`
|
||||
|
||||
Which file types, attributes, etc. are *not* preserved?
|
||||
-------------------------------------------------------
|
||||
|
@ -187,6 +190,8 @@ all the part files and manually concatenate them together.
|
|||
|
||||
For more details, see :ref:`checkpoints_parts`.
|
||||
|
||||
.. _faq_corrupt_repo:
|
||||
|
||||
My repository is corrupt, how can I restore from an older copy of it?
|
||||
---------------------------------------------------------------------
|
||||
|
||||
|
|
|
@ -1,4 +1,3 @@
|
|||
|
||||
.. somewhat surprisingly the "bash" highlighter gives nice results with
|
||||
the pseudo-code notation used in the "Encryption" section.
|
||||
|
||||
|
@ -13,6 +12,8 @@ Security
|
|||
Cryptography in Borg
|
||||
====================
|
||||
|
||||
.. _attack_model:
|
||||
|
||||
Attack model
|
||||
------------
|
||||
|
||||
|
|
|
@ -389,9 +389,8 @@ For automated backups the passphrase can be specified using the
|
|||
Make a backup copy of the key file (``keyfile`` mode) or repo config
|
||||
file (``repokey`` mode) and keep it at a safe place, so you still have
|
||||
the key in case it gets corrupted or lost. Also keep your passphrase
|
||||
at a safe place.
|
||||
|
||||
You can make backups using :ref:`borg_key_export` subcommand.
|
||||
at a safe place. You can make backups using :ref:`borg_key_export`
|
||||
subcommand.
|
||||
|
||||
If you want to print a backup of your key to paper use the ``--paper``
|
||||
option of this command and print the result, or print this `template`_
|
||||
|
@ -400,6 +399,12 @@ For automated backups the passphrase can be specified using the
|
|||
A backup inside of the backup that is encrypted with that key/passphrase
|
||||
won't help you with that, of course.
|
||||
|
||||
In case you lose your repository and the security information, but have an
|
||||
older copy of it to restore from, don't use that later for creating new
|
||||
backups – you would run into security issues (reuse of nonce counter
|
||||
values). It is better to initialize a new Borg repository. See also:
|
||||
:ref:`faq_corrupt_repo`
|
||||
|
||||
.. _template: paperkey.html
|
||||
|
||||
.. _remote_repos:
|
||||
|
|
Loading…
Add table
Reference in a new issue