Dear Kern, Thanks for this, I'll get the test version patched sometime in the next 2-3 days.
Best Regards, Brett -----Original Message----- From: Kern Sibbald [mailto:[EMAIL PROTECTED] Sent: 15 August 2005 17:56 To: Brett Delle Grazie Cc: bacula-users@lists.sourceforge.net; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [Bacula-users] Backup / Restore of DB2 Databases using Fifo's On Monday 15 August 2005 17:55, [EMAIL PROTECTED] wrote: > Dear Kern, > > I'm inclined to agree with Phil & Thomas and your own comments. > > Since the FileSet we use includes the 'readfifo' option, why not: > never overwrite an existing fifo if this option is set on a restore > operation? You might try applying the attached patch file to version 1.36.3 (possibly 1.36.2). cd <bacula-source> patch -p0 <raw.patch make ... > > It then becomes the Run before client's job to create this fifo with the > appropriate permissions such that bacula and the pipe reader software can > utilise it. > > Best Regards, > > Brett Delle Grazie > > -----Original Message----- > From: Kern Sibbald [mailto:[EMAIL PROTECTED] > Sent: 13 August 2005 13:40 > To: bacula-users@lists.sourceforge.net > Cc: Phil Stracchino; Thomas E. Ruth; Brett Delle Grazie; bacula-devel > Subject: Re: [Bacula-users] Backup / Restore of DB2 Databases using > Fifo's > > > Hello Phil, > > On Friday 12 August 2005 20:52, Phil Stracchino wrote: > > Thomas E. Ruth wrote: > > > I havn't been able to automate a restore completely within bacula for > > > DB2 databases, but I've gotten close. The bacula restore process > > > creates a FIFO with only root permissions but doesn't change the > > > permissions of the actual fifo file until data starts restoring to it. > > > At that time though, it's too late for the DB2 process (I think the > > > file is actually deleted and re-created and the DB2 process loses it's > > > handle on it). > > > > After thinking about what's going on here, I think this is a behavioral > > error on Bacula's part. I suspect that *by default*, Bacula should > > never overwrite a FIFO that already exists during a restore. If it's > > not there, fine, restore it; if it's already there, LEAVE IT ALONE, we > > don't want to break anything. Write any data to it that's supposed to > > be written to it, sure, but if we delete and recreate the FIFO, we may > > break things -- as in this example. > > I think you are on to something here. > > Originally, Bacula did not "touch" the directory entry for a file that > existed, but I forget exactly why, but I was convinced to delete each file > before restoring it. I had forgotten this until it came up with some work > that Thorsten is doing. Deleting files before recreating them, has, in > general, improved restoration. However, it appears that in this case, it > breaks the ability to use a FIFO to restore a file as Tom wants to do. > > In general, I don't like things that are not symmetric or uniform -- i.e. > why delete most files but not FIFOs before re-creating them? I need to > think about this for a bit and look at the code ... > > > This probably applies to socket pseudo-nodes as well, assuming we even > > restore those at all (which I still believe we shouldn't). -- Best regards, Kern ("> /\ V_V ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
