Hello Damiano, thank you very much for your detailed mail. I really appreciate your effort to write.
Am 29.08.2017 um 12:33 schrieb Damiano Verzulli: > Following this list, I noticed this message: > > > /From: *Philipp Storz* <philipp.storz@*****.com> > Date: 2017-08-28 9:36 GMT+02:00 > Subject: Re: [bareos-users] Always Incremental backups are awesome > To: [email protected] <mailto:[email protected]> > [....] > Thank you very much for giving positive feedback, as most of the time we > only get negative > feedback of different kinds, partly even quite impudent which can be > quite demotivating./ > > I know very well such a "feeling", as it's very common also here, in my > office :-) > > So I just decided to take away 10 minutes, and write the following. > > We come from a Bacula deployment (2005-2013, more or less) and then switched > to BareOS as of 2013 > (more or less; up to now). Our current BareOS infrastructure is not the > biggest of the world but... > I think it's relevant: > > * 1 (very old) tape-library with 24 magazines and one LTO3 drive; > * 1 (old) tape-library with 24 magazines and two LTO5 drive; > * 1 HP-microserver GEN8 (with 4x8TB SATA drives, SW-RAID-10), acting as a > (fast/RAID10) FD; > * 1 HP-microserver GEN8 (with 4x8TB SATA standalone drives), acting as SD; > * an architecture involving different boxes for DIR+DB and three SDs; > > As of workload, we have: > > * 44 clients (mostly linux servers; some windows one) > * 1 small set of "heavy clients" (our mailserver backends), each one with > something like 5M files > and 1.5TB of data (messages stored in maildir); > * other not-so-much-interesting clients > > _*All the above.... simply ROCKS*_! I really cannot imagine our "backup > strategy" performed with > different technologies. Great, I am very happy to hear that. > This can sound a bit "biased" as I'm sort of F/OSS addicted and not so much > aligned with current > proprietary/legacy backup solutions... but.... the couple made by BareOS and > Open-Source it's really > invaluable (in more than ten years, we had some events requiring us "raw" > access to data, and it has > always been possible, thanks to the "open-source" model!). Not to mention the > feeling of real > freedom that I have when thinking to what (and HOW) is stored inside my LTO > cartridge or, also, when > planning "updates" (HW/SW). Very difficult to explain to non-experts, > unfortunatly. Yes, that is the key point to use open source software in backup. Usually, you have legal requirements to keep certain data for multiple years. If you have used a closed-source product that uses its own backup format, you are locked in and need to pay licenses for as many years as you need to keep your data to be sure you can recover it. With open source software, you can always access your data; no matter what happens, and that is in our view how it should be. > As for the "minus" side or, better, as to something that could be improved > (in general terms), here > are my points: > > * Virtualization: we're a full open-source shop and, as such, we're > (currently) relying on > XenServer. Currently we're SNAPSHOTting the VMs and exporting those > exports to a central NFS > server. From there, when needed, moving the image to the backup archive. > Due to such > not-optimized model, lots of VMs have the BareOS-FD on-board (so we're > backupping DATAs, and not > the VM). I know that for VMware environment BareOS support storage-api to > have "differential" > image-backup: have not tested that. Anyway, I really feel that in the > long run, something (don't > know what!) need to be done in order to improve the backup effectiveness > of open-source > environment (I'm thinking to XENServer, to ProxMox and, in general, to > those technologies that > rely on Linux LVM/FileSystem/Whatever as storage backend). Probably the > solution have to be more > "storage-driven" then "hyphervisor-drive" (=> we focus on the storage > containing the data... and > not on the API provided by the hyphervisor). But I don't have clear ideas > on this. Sure, we have many ideas what can be improved, and of course we also have already thought about what you are saying here. The problem is that development of new features requires a lot of resources. New features need to be developed, tested, documented and so on. Our developers need to be paid, and so we mostly concentrate on the features that our paying customers request. It is interesting that some people seem to think that only because we write open source software and put the source code into the public, we also have to work for free. This is of course not the case. So if a new feature is needed, we need either somebody who wants to do the development together with us. If not, we of course would be happy to do sponsored development of certain features, which need to be paid once and then will be available in the product for everybody, and will be maintained also in future versions. > On a much lower "desiderata" scale, I've also to say that: > > * Documentation is really high-quality level. It's not common --for me-- to > find other Open-Source > project with a so-deep and well-structured "manual". Anyway, the fact > that just following this > very list I "learn" about commands/concepts that I simply missed in ten > years... probably means > that we need also some other kind of docs (what kind? Don't know...). Thanks you very much for the good feedback on the documentation, I am happy that Jörg did the great job to do the docs and to keep it up-to-date. Writing documentation is unfortunately something that takes really a lot of time and needs to be done right. We would be very happy if somebody wants to join the documentation team and help to improve it. Additionally, we offer bareos training that can maybe help people to come up to speed with bareos. > > The above lead me to a final point: > > * I really think that BareOS is _ENTERPRISE_GRADE_ and, as such, should be > approached by > experienced technicians or, at least, by people that are ready to.... > "suffer" while "doing the > hard work". This is clearly stated in the manual: "/if you are new to > Unix systems or do not > have offsetting experience with a sophisticated backup package, the Bareos > project does not > recommend using Bareos/". Probably this concept is still not very clear > among young BareOS > adopters and something could be done to better express the concept (IMHO > the problem, here, is > that people approaching BareOS/Backup in a professional way tipically > lacks the fundamental > concepts of such backups technologies and so are simply unable to "get" > the idea of complexity > behind it. WebUI is one example of this problem: I see lots and lots and > lots of people using > WebUI for their day-by-day activity. There's nothing wrong with such a > choice... despite that in > large deployments you simply cannot blindly use a web-interface to manage > such a complex thing > like a restore from a large backup. From one point, I second the idea > that a Web Interface is > needed. But from another point, a sort of disclaimer like: "if you don't > have an idea about the > overal process undergoing your web-clicks... please, don't use it!". > Probably a middle step > could be improving technologies behind WebUI: I spent some time thinking > to this and.... I'm > really convinced that by employing a WebSocket between a > "server-component" (a daemon written in > an high-level language like Python or Perl and talking with the director > via a persistent socket > connection) and the WebUI could solve _LOTS_ (all?) of the problems > caused by the intrinsic > stateless model of the web. This, probably, is something to discuss > (here? I don't know...) Well, we have our open source backup conference, where I woul be very happy to see you and we can discuss everything you want, see: http://osbconf.org/ > > And, to close: > > * I think, sometime, about "how" to foster BareOS development and as #1 > action I would choose: > "asking for professional services". Actually, right now, I'm planning a > sort of "Backup > Infrastructure, 3.0", expanding our disk-based SDs (HP microservers) to > bigger boxes like DELL > r730XD with lots of drives. Also, a better planning about backup flows > (source system => > intermediate disks => tapes) is under discussions, here. Those are > _exceptional_ topics for a > professional-level consultancy service. But we are in Italy. We are also > a Public Entities. So > it's absolutely complex (to not say "impossible") to get such services > from abroad. What can we > do? I'm really interested in ideas.... Regarding professional a colleague will contact you directly. > That's all! > > And don't forget: I'm really convinced that BareOS is something to consider > on-par with Apache, > Samba, Postfix, Dovecot.... (OK. You got the idea) > > Cheers, > > DV Damiano, thank you very much for the feedback, and I would be happy if we could meet on the osbconf. Best regards, Philipp -- Mit freundlichen Grüßen Philipp Storz [email protected] Bareos GmbH & Co. KG Phone: +49 221 63 06 93-92 http://www.bareos.com Fax: +49 221 63 06 93-10 Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646 Geschäftsführer: Stephan Dühr, M. Außendorf, J. Steffens, P. Storz -- You received this message because you are subscribed to the Google Groups "bareos-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
