• 3 Posts
  • 19 Comments
Joined 1 year ago
cake
Cake day: June 17th, 2023

help-circle

  • It is unrealiatic, that in a stable software release there is suddenly, after you tested your backup a hard bug which prevents recovery.

    How is unrealistic? Think of this:

    • day 1: you backup your files, test the backup and everything is fine
    • day 2: you store a new file that triggers a bug in the compression/encryption algorithm of whatever software you use, now backups are corrupted at least for this file Unless you test every backup you do, and consequently can’t backup fast enough, I don’t see how you can predict that future files and situations won’t trigger bugs in a software

  • Going unmaintained is a non issue, since you can still restore from your backup. It is not like a subscription or proprietary software which is no longer usable when you stop to pay for it or the company owning goes down.

    Until they hit a hard bug or don’t support newer transport formats or scenarios. Also the community dries up eventually



  • how does this look safer for rsync? For me it looks like the risk for that is similar, but I might not know background of development for these.

    Rsync is available out of the box in most linux distro and is used widely not only for backups, but a lot of other things, such as repository updates and transfers from file hosts. This means a lot more people are interested in it. Also the implementation, looking at the source code, is cleaner and easier to understand.

    how do you deal with it when just a file changes?

    I think you should consider that not all files are equal. Rsync for me is great because I end up with a bunch of disks that contain an exact copy of the files I have on my own server. Those files don’t change frequently, they are movies, pictures, songs and so on.

    Other files such as code, configuration, files on my smartphone, etc… are backup up differently. I use git for most stuff that fits its model, syncthing for my temporary folders and my mobile phone.

    Not every file can suit the same backup model. I trust that files that get corrupted or lost are in my weekly rsync backup. A configuration file I messed up two minutes ago is on git.



  • I am simple man s I use rsync.

    Setup a mergerfs drive pool of about 60 TiB and rsync weekly.

    Rsync seems daunting at first but then you realize how powerful and most importantly reliable it is.

    It’s important that you try to restore your backups from time to time.

    One of the main reasons why I avoid softwares such as Kopia or Borg or Restic or whatever is in fashion:

    • they go unmantained
    • they are not simple: so many of my frienda struggled restoring backups because you are not dealing with files anymore, but encrypted or compressed blobs
    • rsync has an easy mental model and has extremely good defaults











  • I used many of them and settled for bare repos on an host with ssh access

    • gitea / gogs: too many database corruptions I am getting ptsd just talking about it
    • gitlab: too big, too resource hungry for something so simple. Didn’t use 90% of the stuff that offered
    • gitbucket and onedev: those are very good and are sort of setup and forget because they just work. They have different features set so check them out.

    In the end given that I just have a bunch of users and don’t need many fancy features (we share patches over email and matrix) on our community server we are just using ssh and klaus as a web frontend