On Sunday 02 September 2007 12:33, Bastian Friedrich wrote: > Hi, > > On Sonntag 02 September 2007, Kern Sibbald wrote: > [...] > > > > FIFOs. This feature is crucial for our needs: Backing up process > > > output instead of files. > > [...] > > > The big problems are that this project is currently rather ill > > defined, and it is rather low in user priority. > > The votes obviously show this low priority; I frankly don't understand > that, though. Every organization/company/unit where a database is set > up (including, but not restricted to SQL DBMS) should need a database > backup system - something that is not currently available in Bacula, > and possibly the most significant difference from the commercial > competitors. YMMV.
Well, "something that is not currently available in Bacula" is not correct. There are currently two ways to accomplish this: 1. Write the data out through a FIFO 2. Write the data out to a file and backup the file. Neither of these may be an ideal solution, but they are what we have and they do work. > > > It suffers from some > > of the same problems that plugins face > > The reason I used the subject I used is that I regard the two subjects > as potentially equivalent: A set of two executables (binary, shell > scripts, ...) in fact defines an interface for a plugin. > > When I wrote my initial mail, I had not yet read James' posting on the > topic. His concerns about incremental and differential backups possibly > result in a third "boolean executable" for the decision on whether to > back up a file/fifo/item. Today, Bacula decides what to backup, so there is no need for a third executable. When plugins are available, we *may* allow the decision to backup or not be an option of the plugin. > > > -- that is how to make the > > Volume self contained after adding this kind of feature. The Volume > > format currently is totally self contained in that a restore requires > > only the FD -- it doesn't even need a current definition of a FileSet > > to work. > > This of course is correct for all machines of interest; with a little > abstraction, though, it is only valid for systems that have a similar > semantics on their file systems. Adding plugins adds a level of > semantics. > > Unfortunately, the current level of file system semantics as required by > Bacula is used by approximately 100% of the systems out there (side > note: the file system available on my PalmOS PDA would _not_ be > sufficient for a Bacula restore), while adding the plugins would lower > this level to, well, approximately 0% :-/ > > > 1. Some important design decisions that permit the Volume to remain > > self contained and independent of FileSet definitions. > > In my oppinion, "if plugins (executables) are used during backup, > equivalent plugins need to be in place during restore, or else a > fallback (e.g. writing stdout to a certain file) jumps in" would be a > valid decision. Unlike a redirection of stdin/stdout interface that you requested, I don't think "writing stdout" will be possible with a plugin. A plugin will not always, but in most cases have its own Stream -- i.e. its own format on the Volume. No other part of Bacula would know how to read the data and interpret it. > > Independence of a FileSet definition can be achieved by storing the > fact "is plugin/executable based, and that plugin is..." along with the > data - e.g. by using a different file name schema, similarly to how > it's done in afbackup. Yes, what you write is perfectly correct, and obvious, but to get there is a lot of detailed design work that has not been done. Getting it right is surprisingly hard. > > > 2. A programmer. > > Er. Yes. :) I think I have a solution for that, but it will take about a year to implement it, namely a commercial Bacula support company, with programmers paid from the support fees. :-) Regards, Kern ------------------------------------------------------------------------- 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-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
