[Borgbackup] bypassing "Cache newer than repo" error

[Sitaram Chamarty]

Hi Marian,

On 10/08/2016 06:13 PM, Marian Beermann wrote:

> On 08.10.2016 14:17, Sitaram Chamarty wrote:
>>> This sounds like you created one repository and copied it to multiple
>>> drives/locations?
>>
>> I was going to say "no way" but it appears that is what I did.  Now I
>> also understand why it's happening only to one specific repo (a rather
>> large one I got lazy about creating the first time, and simply did a
>> copy).  I'd clean forgotten!
>>
>>> You can change the repository ID in the "config" file of the repository
>>> (it's hex, keep it the same length), which separates the repositories.
>>
>> I assume it has no other semantics so I can just randomly change some
>> hex digits into others?
> 
> Yes.
> 
> Caveat: if you use key-file mode you'll have to make the same change in
> the key files you use. The default location is
> ~/.config/borg/keys/<names>. Every key file starts with "BORG_KEY
> <repository ID>", that's where you need to make the change.

Thanks.  I don't use keyfile but it's good to know.

> In repokey or unencrypted mode this doesn't matter.
> 
>>> Note: for encrypted repositories it's a very unsafe thing to have
>>> multiple independently updated copies of a repository; if they diverge
>>> (minutely different contents) and an attacker gains access to more than
>>> one copy, the privacy of the repository contents may be compromised.
>>
>> I do have multiple independently updated copies of a repo, but -- other
>> than this one where #2 was created by a file-system level copy of #1,
>> all the others are "borg init"-ed independently on each disk.
>>
>> The passphrase I use is the same, but I assume the internal key was
>> randomly generated each time and would not be the same, so the attack
>> you speak of should not happen for those repos even if someone got hold
>> of them.
>>
>> Is that understanding correct?
> 
> Repositories independently "borg init"-ed are really independent, no
> problems there.
> 
> But in the case, where you "borg init" and then copy (cp -r / rsync /
> etc.) the repo the keys will also be the same. This possibly leads to
> the situation where different data is encrypted with the same key, which
> is highly problematic.

Thanks for confirming my understanding.  (Yeah that one repo is at risk;
I'll delete the two copies and start new, separate, repos on each disk).

Thanks again!

regards
sitaram

> 
> Cheers, Marian
> 
>> Thanks again and best regards
>> sitaram
>>
>>>
>>> Cheers, Marian
>>>
>>> FAQs:
>>>
> http://borgbackup.readthedocs.io/en/stable/faq.html#can-i-copy-or-synchronize-my-repo-to-another-location
>>>
>>> On 08.10.2016 13:06, Sitaram Chamarty wrote:
>>>> Hi
>>>>
>>>> Some of the directories are backed up to two (in one case three)
>>>> different external (USB) hard disks.  When I finish with the first USB
>>>> drive, unmount it, and mount the next one and try the backup, borg tells
>>>> me the cache is newer.
>>>>
>>>> I could not find anything about how to bypass this in the docs.  I have
>>>> now created a complicated system of separately maintaining the cache
>>>> directories for each external disk (labelled in some way that correlates
>>>> with the physical disk in question) and manually shuffle them around.
>>>>
>>>> Any pointers would be appreciated.
>>>>
>>>> regards
>>>> sitaram
>>>>
>>>> PS: Yes removing ~/.cache/borg works and is generally harmless.  But
>>>> that makes ALL the files show up as "A ...", whereas I like to eyeball
>>>> the list to see if something got updated which I did not expec to be
>>>> updated based on what I have been working on since the last backup.
>>>> _______________________________________________
>>>> Borgbackup mailing list
>>>> Borgbackup at python.org
>>>> https://mail.python.org/mailman/listinfo/borgbackup
>>>>
>>>
>>> _______________________________________________
>>> Borgbackup mailing list
>>> Borgbackup at python.org
>>> https://mail.python.org/mailman/listinfo/borgbackup
>>>
>>
>