really sparse.
\label{readfifo}
-
\item [readfifo=yes|no]
\index[fd]{readfifo }
If enabled, tells the Client to read the data on a backup and write the
FIFO. When this is not enabled (default), the Client simply saves the
directory entry for the FIFO.
+ Unfortunately, when Bacula runs a RunBeforeJob, it waits until that
+ script terminates, and if the script accesses the FIFO to write
+ into the it, the Bacula job will block and everything will stall.
+ However, Vladimir Stavrinov as supplied tip that allows this feature
+ to work correctly. He simply adds the following to the beginning
+ of the RunBeforeJob script:
+
+\begin{verbatim}
+ exec > /dev/null
+\end{verbatim}
+
+
\item [mtimeonly=yes|no]
\index[dir]{mtimeonly }
If enabled, tells the Client that the selection of files during
\end{verbatim}
\normalsize
- if {\bf /home/abc/fifo} is a fifo device, Bacula will open the fifo, read it,
- and store all data thus obtained on the Volume. Please note, you must have a
- process on the system that is writing into the fifo, or Bacula will hang,
- and after one minute of waiting, Bacula will give up and go on to the next
- file. The data read can be anything since Bacula treats it as a stream.
-
- This feature can be an excellent way to do a "hot" backup of a very large
- database. You can use the {\bf RunBeforeJob} to create the fifo and to start
- a program that dynamically reads your database and writes it to the fifo.
- Bacula will then write it to the Volume.
-
- During the restore operation, the inverse is true, after Bacula creates the
- fifo if there was any data stored with it (no need to explicitly list it or
- add any options), that data will be written back to the fifo. As a
- consequence, if any such FIFOs exist in the fileset to be restored, you must
- ensure that there is a reader program or Bacula will block, and after one
- minute, Bacula will time out the write to the fifo and move on to the next
- file.
+ if {\bf /home/abc/fifo} is a fifo device, Bacula will open the fifo,
+ read it, and store all data thus obtained on the Volume. Please note,
+ you must have a process on the system that is writing into the fifo, or
+ Bacula will hang, and after one minute of waiting, Bacula will give up
+ and go on to the next file. The data read can be anything since Bacula
+ treats it as a stream.
+
+ This feature can be an excellent way to do a "hot" backup of a very
+ large database. You can use the {\bf RunBeforeJob} to create the fifo
+ and to start a program that dynamically reads your database and writes
+ it to the fifo. Bacula will then write it to the Volume. Be sure to
+ read the \ilink{readfifo section}{readfifo} that gives a
+ tip to ensure that the RunBeforeJob does not block Bacula.
+
+ During the restore operation, the inverse is true, after Bacula creates
+ the fifo if there was any data stored with it (no need to explicitly
+ list it or add any options), that data will be written back to the fifo.
+ As a consequence, if any such FIFOs exist in the fileset to be restored,
+ you must ensure that there is a reader program or Bacula will block, and
+ after one minute, Bacula will time out the write to the fifo and move on
+ to the next file.
\end{itemize}
\subsubsection*{FileSet Examples}
\index[general]{FileSet Examples}
\addcontentsline{toc}{subsection}{FileSet Examples}
-The following is an example of a valid FileSet resource definition. Note, the
-first Include pulls in the contents of the file {\bf /etc/backup.list} when
-Bacula is started (i.e. the @), and that file must have each filename to be
-backed up preceded by a {\bf File =} and on a separate line.
+The following is an example of a valid FileSet resource definition. Note,
+the first Include pulls in the contents of the file {\bf /etc/backup.list}
+when Bacula is started (i.e. the @), and that file must have each filename
+to be backed up preceded by a {\bf File =} and on a separate line.
\footnotesize
\begin{verbatim}
projects / bacula / docs / blobdiff