Re: Questions about rdiff-backup

[Kevin Fenzi]

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/rd...
>  
>  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