> Of all the projects on the projects list, which 2 or 3 do you think are > most > important from an enterprise standpoint?
That's a very open-ended question...8-) Careful what you wish for. IMHO, here's what my wish list would be: Copypools Extract capability (#25) Continued enhancement of bweb Threshold triggered migration jobs (not currently in list, but will be needed ASAP) Client triggered backups Complete rework of the scheduling system (not in list) Performance and usage instrumentation (not in list) To explain further: The reasoning for the copypool work is in the project list discussion. It's mandatory for regulatory compliance in a lot of industries, and becoming more necessary as even small organizations can mass more disk storage than they can back up easily on removable media. With 500G media, damaged or lost media is a major problem. The extract capability (I think we've discussed this before) is the problem of how to remove data from Bacula's control to systems that don't necessarily have Bacula tools. I would like to see that capability implemented for 'tar' and 'zip' archives (eg, the output of the Bacula "Extract" job is a tar or zip archive suitable for processing outside the Bacula environment. This might be a special pool media type or a special job type, your call. Bat vs bweb. Bat is really nice, but at this point, it's a hard sell to an enterprise for a heavy client option; they really want a) line mode for scripting integration, and b) www-based interfaces that don't require installation on client systems. Bweb is getting better and better and while bat is flashy and cool, the bweb option is probably more interesting for commercial users, and is more suitable for building appliance implementations. Threshold-triggered migration jobs are going to be important for enterprise customers. Their workload varies widely, and the point of managed storage for them is that the computer does the work, not the people. Having Bacula manage and trigger it's own migration processes based on thresholds is an important part of that. Client triggered backups. Important for managing firewall issues, but also makes implementing scheduler changes easier. Rework of the scheduling system. The current model is very complex to understand, and the current centralized job initiation model has problems scaling into enterprise space (we currently have problems with it in a large environment of >2000 clients, and have simply shut off the Bacula scheduler and gone to external event scheduling). A suggestion might be to add a client schedule management daemon that retrieves a schedule from a central server, and then kicks off a client-triggered backup at the appropriate time distributes a lot of the load. If the scheduling component were separated from the job management in the director, it'd also be a nice step toward separating all the event-driven components of Bacula into a event manager daemon that could handle monitoring thresholds, etc. Might also make sense to move the reporting functions out of the director as well, as the scheduling component would likely have all the information needed to do useful reporting. Wrt to performance/usage instrumentation, it'd be really useful to be able to natively monitor the operation of Bacula with enterprise console tools like OpenView or similar widgets. This would imply SNMP interfaces and other work beyond what has been done in the Nagios plugins. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
