From 10a4e011c01943987f222375b5839d084bf8a40c Mon Sep 17 00:00:00 2001 From: anarcat Date: Sun, 10 Feb 2019 14:23:59 -0500 Subject: [PATCH] add warnings on repository copies to avoid future problem like #4272 (#4285) docs: add warnings about repo copies to avoid problems like #4272 --- docs/faq.rst | 62 ++++++++++++++++++++++++++++++++++++---------------- 1 file changed, 43 insertions(+), 19 deletions(-) diff --git a/docs/faq.rst b/docs/faq.rst index 661f7b790..10d1544a7 100644 --- a/docs/faq.rst +++ b/docs/faq.rst @@ -26,29 +26,53 @@ or deleting archives, which may make *simultaneous* backups fail. Can I copy or synchronize my repo to another location? ------------------------------------------------------ -Yes, you could just copy all the files. Make sure you do that while no -backup is running. If you copy a repository while a backup is running, -the lock held will be present in the copy. Thus, before using borg on the copy -from a different host, you need to use :ref:`break-lock` on the copied -repository, because Borg is cautious and does not automatically remove -stale locks made by a different host. - -So what you get here is this: - -- client machine ---borg create---> repo1 -- repo1 ---copy---> repo2 - -There is no special borg command to do the copying, just use cp or rsync if -you want to do that. - -But think about whether that is really what you want. If something goes -wrong in repo1, you will have the same issue in repo2 after the copy. - -If you want to have 2 independent backups, it is better to do it like this: +If you want to have redundant backup repositories (preferably at separate +locations), the recommended way to do that is like this: +- ``borg init repo1`` +- ``borg init repo2`` - client machine ---borg create---> repo1 - client machine ---borg create---> repo2 +This will create distinct repositories (separate repo ID, separate +keys) and nothing bad happening in repo1 will influence repo2. + +Some people decide against above recommendation and create identical +copies of a repo (using some copy / sync / clone tool). + +While this might be better than having no redundancy at all, you have +to be very careful about how you do that and what you may / must not +do with the result (if you decide against our recommendation). + +What you would get with this is: + +- client machine ---borg create---> repo +- repo ---copy/sync---> copy-of-repo + +There is no special borg command to do the copying, you could just +use any reliable tool that creates an identical copy (cp, rsync, rclone +might be options). + +But think about whether that is really what you want. If something goes +wrong in repo, you will have the same issue in copy-of-repo. + +Make sure you do the copy/sync while no backup is running, see +:ref:`borg_with-lock` about how to do that. + +Also, you must not run borg against multiple instances of the same repo +(like repo and copy-of-repo) as that would create severe issues: + +- Data loss: they have the same repository ID, so the borg client will + think they are identical and e.g. use the same local cache for them + (which is an issue if they happen to be not the same). + See :issue:`4272` for an example. +- 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. + Which file types, attributes, etc. are *not* preserved? -------------------------------------------------------