Re: I uninstalled OpenMediaVault (because totally overkill for me) and replaced it with borgbackup and rsyncq
On Fri, 2023-09-01 at 23:15 +0200, Linux-Fan wrote:
> Default User writes:
>
> > On Fri, 2023-09-01 at 07:25 -0500, John Hasler wrote:
> > > Jason writes:
> > > > Or how does your backup look like?
>
> See https://lists.debian.org/debian-user/2019/11/msg00073.html
> and https://lists.debian.org/debian-user/2019/11/msg00420.html
>
> > > Just rsync.
> >
> >
> > Sorry, I just couldn't resist chiming in here.
> >
> > I have never used OpenMediaVault.
> >
> > 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?
>
> I am currently using `bupstash` (not in Debian unfortunatly) and
> `jmbb`
> (which I wrote for myself in 2013) in parallel and am considering
> switching
> to `bupstash` which provides just about all features that I need.
>
> Here are my notes on these programs:
> * https://masysma.net/37/backup_tests_borg_bupstash_kopia.xhtml
> * https://masysma.net/32/jmbb.xhtml
>
> And also the Bupstash home page:
> * https://bupstash.io/
>
> IMHO borg is about the best backup program that you can get from the
> Debian
> repositories (if you need any of the modern features that is). The
> only
> issue I really had with it is that it was too slow for my use cases.
>
> > In the end, I currently have settled upon using rsnapshot to back
> > up my
> > single-machine, single-user setup to external external usb hard
> > drive
> > A, which is then copied to external usb hard drive B, using rsync.
> > If
> > you can do rsync, you can do rsnapshot.
> >
> > It's easy, especially when it comes to restoring, verifying, and
> > impromptu access to data, to use random stuff, or even to just
> > "check
> > on" your data occasionally, to reassure yourself that it is still
> > there.
> >
> > Yes, it does require considerable space (no data de-duplication),
> > and
> > the rsync of the backup drives does take considerable time. But to
> > me,
> > it is worth it, to avoid the methodological equivalent of "vendor
> > lock-
> > in".
>
> Yes, the “vendor lock-in” is really a thing especially when it comes
> to
> restoring a backup but the fancy backup software just does not
> compile for
> the platform or is not available for other reasons or you are stuck
> on a
> Windows laptop without Admin permissions (wost case scenario?).
>
> I mitigated this with `jmbb` by providing for a way to restore
> individual
> files also using third-party utilities and I intend to mitigate this
> for
> `bupstash` by writing my own restore program
> (work-in progress: https://masysma.net/32/maxbupst.xhtml)
>
> > INB4: No, I don't do online backups. If people or organizations
> > with
> > nose problems want my data they are going to have to make at least
> > a
> > little effort to get it. And yes, I do know the 1-2-3 backup
> > philosophy, which does seem like a good idea for many (most?)
> > users.
>
> The problem I have with offline backups that it is an inconvenience
> to carry
> around copies and that this means they are always more out of date
> than I
> want them to be. Hence I rely on encryption to store backups on
> untrusted
> storages.
>
> [...]
>
> Short but comprehensive resource on the subject (includes some
> advertising /
> I am not affiliated / maybe this has outlived the product it
> advertises for?):
> http://www.taobackup.com/index.html
>
> YMMV
> Linux-Fan
>
> öö
1) I did read http://www.taobackup.com/index.html a while back. It is
an ad, but funny and worth the read nevertheless.
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".
So, I posted the problem to the borg mailing list. And my jaw hit the
floor. I was astounded that no one there was able to say that it is
even possible to do such a repository copy/restore, let alone how to do
so!
The best advice was to just create a new repository and start a new
backup series, starting now and going forward. For exmple, let's say
the original series started 2022-01-01. And the repository A "problem"
started 2023-01-01. If I just created a new repository A, starting with
a new series beginning with 2023-01-01, then I only have one copy of
the data from 2022, in repository B. If repository B ever fails, I
have no data at all from 2022!
This was of course just unacceptable to me.
And I started thinking:
The borg website bluntly says that they will keep changing borg,
without regard for backward compatibility. (systemd, anyone?). I have
heard that NASA has unusable data from the early days of the space
program. The data is fine. But can't be used because the hardware
and/or software to use it no longer exists.
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.
Reply to: