Is it possible to “fork” a borg repository?

[spaceChRiS]

I want to add a new backup medium and want to preserve the backup history of my other backup media (at least of one of them) also on the new medium. How can I get the history into a new repository other than fuse-mounting the “old” borg repository and creating a backup of it in the “new” borg repository, as this method has several drawbacks:

• The new backup will see all the files relative to /mountpoint, which makes restore more difficult.
• The performance might be much worse than a direct copy of the original repo with cp or dd due to the fuse mount.
  But a direct copy to a new drive will not change the repositories metadata, which means a simple copy will cause trouble if both repositories are still operated in the future.

Is there a method that I missed? Btw, the repository size is approx. 8 TB such that just copying the old repoo and starting a new one with the new backup is a no-go as it would double the needed space on the medium, which it does not have. #6286 (comment) looks like that might be possible by copying and then changing metadata, but I want to be sure to not break my existing backups.

[Utopiality7]

To seamlessly transition your backup history to a new medium using Borg, you might want to explore the borg transfer feature, which is designed to move archives between repositories smoothly. This method ensures that all metadata remains intact, avoiding the pitfalls of duplicating data as would happen with simple file system tools like cp or dd.

Start by setting up your new repository and then run borg transfer to bring the archives over from the old location. It’s a good idea to give this process a trial run on a smaller set of data first to make sure everything functions as expected. Before diving in, make sure you have a backup of your essential data just in case. And of course, the Borg documentation is there to guide you through the finer details if needed.

[spaceChRiS]

“transfer” sounds like an exciting new feature in borg 2, but I am a bit reluctant testing it on my production data as it is still in beta. I'm looking forward to testing the new version, but I need to perform this particular task before … I asked below for the best practice for borg 1 anyway, but thanks for introducing me to this great addition!

[RonnyPfannschmidt]

Rsync of the repo followed by altering the id in the new location

It's a hack

[RonnyPfannschmidt]

Borg2 will support transfers

In borg1 cloning the repo requires some hands on approach

[spaceChRiS]

In borg1 cloning the repo requires some hands on approach

What is the recommended way in borg 1? I mean I could do borg export-tar /path/to/old-repo::snapshot - | borg import-tar /path/to/new-repo::snapshot - for each snapshot but this will likely transfer the entire data for every “snapshot” and all will be hashed, just to drop most of the data then, as it is already in the new repository after the first snapshot is processed ...

[ThomasWaldmann]

In borg1, there is no perfect way to clone (duplicate) a repo (so you could use 2 perfect repos afterwards independently):

• the borg mount method might be a bit slow and borg mount does not support all metadata (e.g. no ACLs)
• the export-tar method does not support all metadata (e.g. no ACLs, no xattrs)
• just copying the whole repo would lead to duplicate repo id (and thus caching problems), crypto issues (nonce reuse) if both repos are updated independently.

The first 2 methods are ok IF you don't need all metadata. File names, simple stat (user, group, mode) and file content will be ok.

[spaceChRiS]

OK, this means there is no way to copy the repository externally and then change the repo ID and metadata? Seems I have to wait for borg 2 and find some intermediate solution in the meantime. Maybe I rsync the repository from one to another backup drive, always only in the same direction. This is not optimal as I will have both backups plus the original data connected at the same time, but at least it's not worse than now. Thanks for the feedback. And thanks for this great software!

[ThomasWaldmann]

Changing the repo id avoids the cache issues, but not the crypto issues.

But if you don't fear a targetted high-profile attack, it might be an option / a risk you could take.