Open Gnarflord opened 5 years ago
Related issue https://github.com/borgbackup/borg/issues/4454
Yup, see #4454.
I somehow feel that the added complexity in the code / error handling / the additional documentation needs by far outweighs whatever might be gained with this feature.
Such behaviour with swtching between multiple repos could be implemented in a short script, which may be the better solution. For example, one could have two locations (0, 1) and choose one by calculating DAY(DATE) mod 2. I don't think Borg needs a choose-a-repo functionality.
borg 2 will have some very limited support to work with multiple repos:
Some more might come in future.
As #8332 did some rather fundamental changes to how the repository works in borg2 (using borgstore
now), we maybe could use borgstore's MStore
for that.
Currently, if we want to secure ourselves against disk failure it's recommended to create two separate borg repositories on separate media and let the client decide where it should push it's backup. I'd like to add a feature, which lets borg handle multiple repositories without annoying the user with the management aspect.
Some thoughs:
When using "borg init" one should be able to give multiple paths for repo creation.
"borg create" should have two modes, depending on user preferences:
Any other command should work with the most recent backup of course.
This should be fairly straight-forward* by adding a generic handler which chooses the right repos and calls the desired command with it.
The reason I want to add those changes is because it would allow for some broader setups. For example consider three disks with repos, of which two are at all times in the backup server and the third at some secure offline location. Regularly one could rotate the disks and let borg automatically fill the oldest one.
Before I start programming I'd like to ask if this feature is wanted or even makes sense. Also I'm not quite sure about the syntax yet. It'd be possible to append something like
to every command but that'd become quite cumbersome. Maybe save the locations as a repo-config and let every repo be aware of it's sister repos?
Any thoughts?
(*) famous last words