Default User writes:
On Fri, 2023-09-01 at 23:15 +0200, Linux-Fan wrote: > Default User writes:
[...]
> > I HAVE used a number of other backup methodologies, including > > Borgbackup, for which I had high hopes, but was highly > > disappointed. > > Would you care to share in what regards BorgBackup failed you?
[...]
2) I used borg for a while. Block-level de-duplication saved a ton of space. But . . . Per the borg documentation, I kept two separate (theoretically) identical backup sets, as repository 1 and repository 2, on backup drive A. Both repositories were daily backed up to backup drive B. Somehow, repository 1 on drive A got "messed up". I don't remember the details, and never determined why it happened. I had a copy of repository 1 on backup drive B, and two copies of repository 2 on backup drive B, so, no problem. I will just copy repository 1 on backup drive B to backup drive A. Right? Wrong. I could not figure out how to make that work, perhaps in part because of the way borg manages repositories by ID numbers, not by repository "names".
[...]
And, what is F/LOSS today can become closed and proprietary tomorrow, and thus unintentionally, or even deliberately, you and your data are trapped . . . (Audacity? CentOS?). So even though borg seems to be the flavor of the month, I decided no thanks. I think I'll just "Keep It Simple". Now if borg (or whatever) works for you, fine. Use it. This is just my explanation of why I looked elsewhere. YMMV.
Thank you very much for taking the time to explain it detailedly.I can understand that corruption / messed up repositories are really one of the red flags for backup tools and hence a good reason to avoid such tools. Hence I can fully understand your decision. That there was no way to recover despite following the tools best practices (docs) does not improve things...
Just a question for my understanding: You mentioned having multiple repositories. If I had the situation with two different repositories and one corrupted my first idea (if the backup program does not offer any internal functions for these purposes which you confirmed using the mailing list?) would be to copy the “good” repository at the file level (i.e. with rsync / tar whatever) and then afterwards update the copy to fixup any metadata that may be wrong. Did you try out this naive approach during your attempt for recovery?
I think that currently I am not affected by such issues because I only keep the most recent state of the backup and do not have any history in my backups (beyond the “archive” which I keep separate and using my own program). Hence for me, indeed, the solution to re-create the repository in event of corruption is viable.
But as the backup programs advertise the possibility to keep multiple states of the backup in one repository, it is indeed, essential, that one can “move around” such a repository on the file system while being able to continue adding to it even after swiching to a different/new location. I have never thought about testing such a use case for any of the tools that I tried, but I can see that it is actually quite the essential feature making it even more strange that it would not be available with Borg?
TIA Linux-Fan öö
Attachment:
pgpsjQCrZlJ0x.pgp
Description: PGP signature