[Bacula-devel] Re: [Bacula-users] Backup / Restore of DB2 Databases using Fifo's

[Kern S. <ke...@si...>]

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