Quoting Kern Sibbald <kern AT sibbald DOT com>:
> Hello Graham,
>
> Thanks for your "Full disclosure".
>
> To answer your question: a *well* tuned Bacula community Director can
> probably handle between 1000-1500 "normal" size jobs per 12 hour backup
> period. A normal job is a normal Linux or Microsoft server that would
> include a few terabytes (say up to 10) of data/server and perhaps on the
> average 1 million files/server. If the data volume goes up
> significantly, one may need to consider multiple Storage daemons as
> there is a certain data throughput that a SD will support. The issues
> with the Director are mostly the total number of files (i.e. the catalog).
>
> A Bacula Enterprise Director can probably handle 5000 similar jobs per
> day.
>
> For others on this list: I have been well aware of the Burp fork since
> its beginning, and I have no problems with it. I have never considered
> it a hostile fork as is the case of Bareos.
>
> That said, there are some minor issues with the Burp fork. If you
> (Graham) are now planning to enter the Enterprise market or do head to
> head competition with Bacula or Bacula Enterprise, we should discuss.
> Nothing really serious and nothing to worry about. It is also curious
> to say that Burp "started out" as a fork of Bacula. Is there a point
> where a fork stops being a fork?
Hello Kern,
Thanks for your reply and the information.
The question about how big an Enterprise is arose because somebody emailed
me to suggest that 1000 burp clients might cause a problem on the server due
to the way they poll. It turns out that he doesn't actually have 1000 clients
and it was just a number he made up. Though it happens to be in the same area
that you have suggested.
I can't imagine any possibility of burp-1.x.x handling that amount of data.
But I have been working on burp-2.x.x, which may (or equally may not) be able
to approach the lower end. I have no way of testing it at that level.
It will probably use more memory and CPU cycles on the client than
bacula does,
because it does variable length chunking and checksumming.
And burp does backups to disk only. I think it would be impossible to
use it to
back up directly to tape like bacula does.
So I don't think that bacula and burp really occupy quite the same space.
I don't have a plan to do head to head competition or enter the Enterprise
market, I just make my software by myself in my spare time. However, it is
possible that somebody more business minded than myself would want to help me
do so in the future (no such person exists right now).
In case that ever happens, I would like to know about the minor issues that
you mention.
Re: fork -
I was using 'started out' to mean 'this is how burp started'.
But I would imagine that it would stop being a fork once the last piece of the
original code was removed. So you are right, it is still a bacula fork because
there is some bacula code that remains.
From the top of my head, that is:
a) The Windows API parts.
b) Some of findlib (though I changed it a lot).
c) base64.c.
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
