Re: Questions about rdiff-backup

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Sep 08, 2020 at 01:45:21AM +0200, Manu Hernandez wrote:
> Thanks for the info, Kevin!

no problem. 

> On 06/09/2020 23:15, Kevin Fenzi wrote:
> > > 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.
> 
> Also, I have read that Eric Lavarde, the current maintainer, works for Red
> Hat. That's a plus too (easier to work with someone in-house)

Well, doesn't really matter as long as it's open source and maintained.
:) 

...snip...

> 
> That makes sense: the NetApp filer does the checksumming (not like ZFS, see:
> https://oshogbo.vexillium.org/blog/73/), snapshots and de-duplication, so
> there is no need for that on the backup application.
> 
> A few more questions about the filer:
> 
> 1.1) Is it managed by RHIT?

yes sort of. We have access to it to do quite a bit of things "self
service". We can adjust exports, setup new volumes, modify existing
volumes, etc etc. RHIT handles larger config (like snapmirroring, see
below) and netapp monitors and replaces failed drives, etc. 
> 
> 1.2) What happens if that NetApp volume "fails"? Just playing devil's
> advocate here: I know this shouldn't be a hardware problem. The filer surely
> has a support contract and NetApp continuously monitors its systems... But
> human error could take down that volume, delete its data, etc.

We have a mirror in another datacenter. It's not everything, but it's
everything important. We also have snapshots, so things can be restored
from a mistaken delete, etc. 

> 1.3) Are there off-site and/or offline backups? Probably if RHIT manages the
> filer, they will take care of this...

Yes, we mirror to a site in RDU.

> > 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.
> 
> Neither I, but thank you for being open to discuss 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.
> 
> To me, using git and ansible to run backup tasks is a bit strange, but
> that's because I have very simple needs at work and at home and I don't
> require the flexibility those tools provide. I understand why they are used
> here.

Yeah, it works. :) 

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

[Index of Archives]     [Fedora Development]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux