Hello Damiano, you are right with your analyses of bareos. Additional I can say it's the only (with bacula) backup system I know that's work secure with DMZs.
Regards Stefan 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. > > 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. > > 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. > > 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...). > > 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...) > > 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.... > > 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 > > -- > 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] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout. -- *CaC, Computer and Communication* Inhaber Stefan Klatt End-2-End Senior Network Consultant Triftstrasse 9 60528 Frankfurt Germany USt-IdNr.: DE260461592 Tel.: +49-(0)172-6807809 Tel.: +49-(0)69-67808-900 Fax: +49-(0)69-67808-837 Email: [email protected] Profil: http://www.cac-netzwerk.de/profil -- 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.
smime.p7s
Description: S/MIME Cryptographic Signature
