Kern, Many thanks for your patch. I have applied it meanwhile (i incorporated it into my RPM spec file and then rebuilt bacula). Then I tested to restore a database through a fifo on my x86_64 box - this worked flawlessly for restoring one single database at a time. Restoring multiple FIFOs with one job still does not work (bacula seems to restore all files to the first fifo), but at least I now know that my backups are good.
Best regards --Marcel >>> Kern Sibbald <[EMAIL PROTECTED]> 28.02.2006 >>> Hello, Attached, please find a patch that can be applied to Bacula 1.38.5 that will fix the bug that prevents restores of read/write fifos from working. I've tested it here and it seems to work fine. This patch does not implement the new proposal I have made, but simply makes the old original code work correctly. The instructions for how to apply the patch are at the top of the file. Best regards, Kern On Monday 27 February 2006 14:31, Marcel Gsteiger wrote: > thank you for your response. Meanwhile I tried several things (e.g. > restoring the database dumpfile to a windows workstation), but I can't > prevent the FD from trying to create the fifo and then fail with permission > conflicts. Sorry but I'm still unable to work it out despite the fact that > you certainly had it made to function some time ago. > > The trouble is that the "Client Run Before Job" script cannot start the > FIFO reader since the FIFOs doesn't yet exist at that time. But when I > create the FIFOs in that script, the FD will subsequently fail while trying > to create them itself. > > One way would be to have the FD start a client side script after creating > each FIFO, perhaps via something like a "Client Run After File Create" > script that takes the file name as a parameter. Alternatively, I could > imagine to have an additional "Replace" option during restore named "fifo" > (in addition to "always", "ifnewer","ifolder", "never") that expects a FIFO > with the name of the file being restored to exist already. The FD should > then leave the other file attributes and date unchecked and write to the > FIFO. > > I would much appreciate if you could help me to make this work. I'm > convinced that I'm not the only one looking for a efficient way to back up > and restore databases, and I believe there is just a small piece missing. > Bacula is already a wonderful piece of software, this would make it even > more usable. > > Regards > -Marcel > > >>> Kern Sibbald <[EMAIL PROTECTED]> 22.02.2006 >>> > > On Wednesday 22 February 2006 17:18, Marcel Gsteiger wrote: > > Hi all > > > > Did anybody succeed to restore a file that was backed up through a fifo? > > I'm unable to get this done. The normal restore job gives an error > > message. I then created a second restore job that re-creates the fifos, > > then tries to restore to the original location. When I set the > > "overwrite" option to never, the system behaves as if it would restore. > > On my pipe, I have a separate task that takes the data and copies it into > > a file. > > > > SD and FD seem to walk through all the data, but at the end the restore > > terminates with a "warning file count mismatch" error and tells me 0 > > files have been restored. > > As the message says, this is not an error, but a warning. Bacula doesn't > really understand FIFOs. > > The question here is not the warning, but did Bacula actually deliver the > contents of the saved file to your program? If so, it worked. If not, > there is some problem, which does not suprise me because I don't have a > regression script for testing FIFOs, and to the best of my knowledge no one > is using this (other than you and perhaps one other person) ... > > > Any ideas? I think the problem is that, in this case, the FD should leave > > my FIFOs prepared via "client run before job" alone. There must be some > > way to perform this, otherwise backing up through FIFOs would be useless. > > It *did* work when I implemented it many years ago. > > > Any help would much be appreciated. > > Regards > > --Marcel > > However, the job always terminates with > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > > files for problems? Stop! Download the new AJAX search engine that > > makes searching your log files as easy as surfing the web. DOWNLOAD > > SPLUNK! > > http://sel.as-us.falkag.net/sel?cmd______________________________________ > >__ _______ Bacula-users mailing list > > Bacula-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bacula-users ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
