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.