Kern Sibbald wrote:
> On Tuesday 07 April 2009 17:32:27 Reynier Perez Mira wrote:
>>> 1.Bacula Release 3.0
>> When will be Bacula 3.0 released during this week?
>
> Since I am working 12-16 hours a day, and I as well as the other developers
> are doing it all for free: It will be ready when it is ready (during this
> week).
For what it's worth, as someone who's done my own fair share of OSS dev
work (on Scribus, PoDoFo, lprof, and misc other things):
*THANKS*
Bacula makes part of my job dramatically simpler, easier, and safer. It
takes some learning and can take some coaxing to get it to do what you
want, but once it's set up it *just* *goes*, and it informs you if/when
something DOES go wrong. I cannot overstate the value of this.
It's also nice to see a project where I start using it and don't
immediately feel the gotta-fix-that-unfeature/bug/whatever itch. Because
Bacula already does what I need it to. Ther are things where it could be
simpler/cleaner/nicer, mostly in configuration, but they're all pretty
minor.
Other backup systems I've investigated (including several commercial
ones) have had weird limitations, horrifying UIs (yes, compared to
Bacula!), and/or scary packaging and setup that makes me reluctant to
let them anywhere near my servers.
Bacula is already integrated into most of the OSes I use, and trivial to
install on the others.
Now that it handles deleted files correctly, it's pretty much perfect.
BTW, if I was to find the time to implement native fd support for LVM
snapshots, so that rather than using pre- and post- scripts for
snapshots and using path stripping, the user could just specify (eg)
"lvm_snapshot=/var/spool/cyrus/mail;2GB" in the FileSet options and have
Bacula take care of managing the snapshot, would that be something you'd
potentially want to see included?
Also, if I was to submit a patch that changed the database format for
post-3.0 to store lstat attributes as individual fields in the DB,
rather than using the almost-base64 encoded strings Bacula currently
uses, would that be considered? I'd *REALLY* like the ability to query
those values directly and to create indexes on them, something I can
currently do only by adding a C helper function to PostgreSQL and using
functional indexes. Kinda clunky. Since (at least in Pg) storage as
native values is at least as storage-efficient as the base64 form, would
this be considered assuming perf testing worked out and it worked OK for
MySQL and SQLite as well?
>> Is the SVN release ready for production?
>
> Yes. This was answered in the first paragraph of the email you are
> citing ... :-)
I've been using 2.5.42b2 for weeks now, by the way, and the only issues
I've encountered have since been fixed in svn.
--
Craig Ringer
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
