On Sat, Sep 05, 2020 at 09:07:51PM +0200, Manu Hernandez wrote: > Hi! > > I was reading this SOP: https://fedora-infra-docs.readthedocs.io/en/latest/sysadmin-guide/sops/rdiff-backup.html > > Hope you don't mind if I ask a few questions about it: Not at all! :) > 1) Why rdiff-backup? There are other alternatives present both in the Fedora > *and* CentOS/RHEL default repos like Amanda or Bacula, and lots more if you > add the EPEL repo (rsnapshot, BackupPC, Borg...) So, first keep in mind that Fedora infrastructure has been around a long time. They are likely things we selected years ago before there were other alternatives. Over the years we have used bacula, a custom thing and then rdiff-backup (which I think we moved to in about 2011 or 2010). It was looking like rdiff-backup would get left behind as it was python2 only and not under active development. Luckily, development revived upstream and they ported to python3 and have been much more active of late. That said, I did look into backups more last year. The two frontrunners on features and activity and such were borg and restic. However, one big issue with both of those is that they work on a model of the client pushing backups to the server. With rdiff-backup we reach out from the server and pull backups from the client. That means in that case that client only has a ssh public key and 0 other access to the server. There are of course ways to restrict access on the server from the clients (restrict to a specific command, borg has 'append only' repo settings, etc). rdiff-backup is also pretty simple, if you need something from the last backup run, you can just copy it off. The backing store for backups is a netapp volume, so it can run de-dupe for space savings and save us from doing it on the application layer. Because of that I didn't see a great need to switch away from rdiff-backup. If there's some good advantage to doing so, we could definitely revisit it. > > 2) The current setup uses a few tools: cron, git, ansible and rdiff-backup. > Wouldn't be simpler to use a tool that just takes care of everything by > itself? Well, all those things are pretty simple and easy to understand. If you have one tool doing them all, it's much less clear how it works or what it's doing. > I'm not questioning this choice, I'm just curious about this tool. I never > used it, so I'm trying to follow the reasoning of it being used to backup > the whole infrastructure. Sure, I completely understand and I'm happy to explan what I know of it. :) kevin
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
