}
\end{verbatim}
-The example above had 2 pool which are copied using the PoolUncopiedJobs selection
-criteria. Normal Full backups go to the Virtual pool and are copied to the Tape pool
-the next morning.
+The example above had 2 pool which are copied using the PoolUncopiedJobs
+selection criteria. Normal Full backups go to the Virtual pool and are copied
+to the Tape pool the next morning.
The command \texttt{list copies [jobid=x,y,z]} lists copies for a given
\textbf{jobid}.
representation from acl\_to\_text (POSIX acl) for access acls.
\item {\bf STREAM\_ACL\_SOLARIS\_ACLENT} 1012 Solaris specific aclent\_t
string representation from acltotext or acl\_totext (POSIX acl)
- \item {\bf STREAM\_ACL\_SOLARIS\_ACE} 1013 Solaris specific ace\_t string representation from
- from acl\_totext (NFSv4 or ZFS acl)
+ \item {\bf STREAM\_ACL\_SOLARIS\_ACE} 1013 Solaris specific ace\_t string
+ representation from from acl\_totext (NFSv4 or ZFS acl)
\end{itemize}
In future versions we might support conversion functions from one type of acl
\section{Exclude Dirs Containing = \lt{}filename-string\gt{}}
\index[general]{IgnoreDir}
-The {\bf ExcludeDirsContaining = \lt{}filename\gt{}} is a new directive that can be added to the Include
-section of the FileSet resource. If the specified
-filename ({\bf filename-string}) is found on the Client in any directory to be backed up,
-the whole directory will be ignored (not backed up).
-For example:
+The {\bf ExcludeDirsContaining = \lt{}filename\gt{}} is a new directive that
+can be added to the Include section of the FileSet resource. If the specified
+filename ({\bf filename-string}) is found on the Client in any directory to be
+backed up, the whole directory will be ignored (not backed up). For example:
\begin{verbatim}
# List of files to be backed up
expression for extracting only a part of the full backup.
\subsection{Bootstrap File Optimization Changes}
-In order to permit proper seeking on disk files, we have extended the
-bootstrap file format to include a {\bf VolStartAddr} and {\bf VolEndAddr}
-records. Each takes a 64 bit unsigned integer range (i.e. nnn-mmm) which defines
-the start address range and end address range respectively. These two directives
-replace the {\bf VolStartFile}, {\bf VolEndFile}, {\bf VolStartBlock} and {\bf VolEndBlock}
-directives. Bootstrap files containing the old directives will still work, but will not
-properly take advantage of proper disk seeking, and may read completely to the end of a
-disk volume during a restore. With the new format (automatically generated by the new
-Director), restores will seek properly and stop reading the volume when all the files
-have been restored.
+In order to permit proper seeking on disk files, we have extended the bootstrap
+file format to include a {\bf VolStartAddr} and {\bf VolEndAddr} records. Each
+takes a 64 bit unsigned integer range (i.e. nnn-mmm) which defines the start
+address range and end address range respectively. These two directives replace
+the {\bf VolStartFile}, {\bf VolEndFile}, {\bf VolStartBlock} and {\bf
+ VolEndBlock} directives. Bootstrap files containing the old directives will
+still work, but will not properly take advantage of proper disk seeking, and
+may read completely to the end of a disk volume during a restore. With the new
+format (automatically generated by the new Director), restores will seek
+properly and stop reading the volume when all the files have been restored.
\subsection{Solaris ZFS/NFSv4 ACLs}
- This is an upgrade of the previous Solaris ACL backup code
- to the new library format, which will backup both the old
- POSIX(UFS) ACLs as well as the ZFS ACLs.
+This is an upgrade of the previous Solaris ACL backup code
+to the new library format, which will backup both the old
+POSIX(UFS) ACLs as well as the ZFS ACLs.
- The new code can also restore POSIX(UFS) ACLs to a ZFS filesystem
- (it will translate the POSIX(UFS)) ACL into a ZFS/NFSv4 one) it can also
- be used to transfer from UFS to ZFS filesystems.
+The new code can also restore POSIX(UFS) ACLs to a ZFS filesystem
+(it will translate the POSIX(UFS)) ACL into a ZFS/NFSv4 one) it can also
+be used to transfer from UFS to ZFS filesystems.
\subsection{Virtual Tape Emulation}
%%
\chapter{Bacula FD Plugin API}
-To write a Bacula plugin, you create a dynamic shared object
-program (or dll on Win32) with a particular name and two
-exported entry points, place it in the {\bf Plugins Directory}, which is defined in the
-{\bf bacula-fd.conf} file in the {\bf Client} resource, and when the FD
-starts, it will load all the plugins that end with {\bf -fd.so} (or {\bf -fd.dll}
-on Win32) found in that directory.
+To write a Bacula plugin, you create a dynamic shared object program (or dll on
+Win32) with a particular name and two exported entry points, place it in the
+{\bf Plugins Directory}, which is defined in the {\bf bacula-fd.conf} file in
+the {\bf Client} resource, and when the FD starts, it will load all the plugins
+that end with {\bf -fd.so} (or {\bf -fd.dll} on Win32) found in that directory.
\section{Normal vs Command Plugins}
-In general, there are two ways that plugins are called. The first way,
-is when a particular event is detected in Bacula, it will transfer control
-to each plugin that is loaded in turn informing the plugin of the event.
-This is very similar to how a {\bf RunScript} works, and the events are very similar.
-Once the plugin gets control, it can interact with Bacula by getting and
-setting Bacula variables. In this way, it behaves much like a RunScript.
-Currently very few Bacula variables are defined, but they will be implemented
-as the need arrises, and it is very extensible.
+In general, there are two ways that plugins are called. The first way, is when
+a particular event is detected in Bacula, it will transfer control to each
+plugin that is loaded in turn informing the plugin of the event. This is very
+similar to how a {\bf RunScript} works, and the events are very similar. Once
+the plugin gets control, it can interact with Bacula by getting and setting
+Bacula variables. In this way, it behaves much like a RunScript. Currently
+very few Bacula variables are defined, but they will be implemented as the need
+arrises, and it is very extensible.
We plan to have plugins register to receive events that they normally would
not receive, such as an event for each file examined for backup or restore.
This feature is not yet implemented.
-The second type of plugin, which is more useful and fully implemented
-in the current version is what we call a command plugin. As with all
-plugins, it gets notified of important events as noted above (details described below),
-but in addition, this kind of plugin can accept a command line, which
-is a:
+The second type of plugin, which is more useful and fully implemented in the
+current version is what we call a command plugin. As with all plugins, it gets
+notified of important events as noted above (details described below), but in
+addition, this kind of plugin can accept a command line, which is a:
\begin{verbatim}
Plugin = <command-string>
\end{verbatim}
directive that is placed in the Include section of a FileSet and is very
-similar to the "File = " directive. When this Plugin directive is encountered
+similar to the "File = " directive. When this Plugin directive is encountered
by Bacula during backup, it passes the "command" part of the Plugin directive
-only to the plugin that is explicitly named in the first field of that command string.
-This allows that plugin to backup any file or files on the system that it wants. It can
-even create "virtual files" in the catalog that contain data to be restored but do
-not necessarily correspond to actual files on the filesystem.
+only to the plugin that is explicitly named in the first field of that command
+string. This allows that plugin to backup any file or files on the system that
+it wants. It can even create "virtual files" in the catalog that contain data
+to be restored but do not necessarily correspond to actual files on the
+filesystem.
The important features of the command plugin entry points are:
\begin{itemize}
bRC unloadPlugin()
\end{verbatim}
-both these external entry points to the shared object are defined as C entry points
-to avoid name mangling complications with C++. However, the shared object
-can actually be written in any language (preferrably C or C++) providing that it
-follows C language calling conventions.
+both these external entry points to the shared object are defined as C entry
+points to avoid name mangling complications with C++. However, the shared
+object can actually be written in any language (preferrably C or C++) providing
+that it follows C language calling conventions.
The definitions for {\bf bRC} and the arguments are {\bf
src/filed/fd-plugins.h} and so this header file needs to be included in
#include <sys/stat.h>
\end{verbatim}
-Aside from the {\bf bc\_types.h} and {\bf confit.h} headers, the plugin definition uses the
-minimum code from Bacula. The bc\_types.h file is required to ensure that
-the data type defintions in arguments correspond to the Bacula core code.
+Aside from the {\bf bc\_types.h} and {\bf confit.h} headers, the plugin
+definition uses the minimum code from Bacula. The bc\_types.h file is required
+to ensure that the data type defintions in arguments correspond to the Bacula
+core code.
The return codes are defined as:
\begin{verbatim}
\end{description}
During each of the above calls, the plugin receives either no specific value or
-only one value, which in some cases may not be sufficient. However, knowing the
-context of the event, the plugin can call back to the Bacula entry points it
-was passed during the {\bf loadPlugin} call and get to a number of Bacula variables.
-(at the current time few Bacula variables are implemented, but it easily extended
-at a future time and as needs require).
+only one value, which in some cases may not be sufficient. However, knowing
+the context of the event, the plugin can call back to the Bacula entry points
+it was passed during the {\bf loadPlugin} call and get to a number of Bacula
+variables. (at the current time few Bacula variables are implemented, but it
+easily extended at a future time and as needs require).
\subsection{startBackupFile(bpContext *ctx, struct save\_pkt *sp)}
This entry point is called only if your plugin is a command plugin, and
does not conflict with a real file on the system, and you need to
artifically create values in the statp packet.
-Example programs such as {\bf bpipe-fd.c} show how to set these fields.
-You must take care not to store pointers the stack in the pointer fields such
-as fname and link, because when you return from your function, your stack entries
-will be destroyed. The solution in that case is to malloc() and return the pointer
-to it. In order to not have memory leaks, you should store a pointer to all memory
-allocated in your pContext structure so that in subsequent calls or at termination,
-you can release it back to the system.
+Example programs such as {\bf bpipe-fd.c} show how to set these fields. You
+must take care not to store pointers the stack in the pointer fields such as
+fname and link, because when you return from your function, your stack entries
+will be destroyed. The solution in that case is to malloc() and return the
+pointer to it. In order to not have memory leaks, you should store a pointer to
+all memory allocated in your pContext structure so that in subsequent calls or
+at termination, you can release it back to the system.
Once the backup has begun, Bacula will call your plugin at the {\bf pluginIO}
entry point to "read" the data to be backed up. Please see the {\bf bpipe-fd.c}
\subsection{endBackupFile(bpContext *ctx)}
-Called at the end of backing up a file for a command plugin. If the plugin's work
-is done, it should return bRC\_OK. If the plugin wishes to create another
-file and back it up, then it must return bRC\_More (not yet implemented).
-This is probably a good time to release any malloc()ed memory you used to
-pass back filenames.
+Called at the end of backing up a file for a command plugin. If the plugin's
+work is done, it should return bRC\_OK. If the plugin wishes to create another
+file and back it up, then it must return bRC\_More (not yet implemented). This
+is probably a good time to release any malloc()ed memory you used to pass back
+filenames.
\subsection{startRestoreFile(bpContext *ctx, const char *cmd)}
Called when the first record is read from the Volume that was
Called when a command plugin is done restoring a file.
\subsection{pluginIO(bpContext *ctx, struct io\_pkt *io)}
-Called to do the input (backup) or output (restore) of data from or to a
-file for a command plugin. These routines simulate the Unix read(), write(), open(), close(),
-and lseek() I/O calls, and the arguments are passed in the packet and
-the return values are also placed in the packet. In addition for Win32
-systems the plugin must return two additional values (described below).
+Called to do the input (backup) or output (restore) of data from or to a file
+for a command plugin. These routines simulate the Unix read(), write(), open(),
+close(), and lseek() I/O calls, and the arguments are passed in the packet and
+the return values are also placed in the packet. In addition for Win32 systems
+the plugin must return two additional values (described below).
\begin{verbatim}
enum {
};
\end{verbatim}
-The particular Unix function being simulated is indicated by the {\bf func},
-which will have one of the IO\_OPEN, IO\_READ, ... codes listed above.
-The status code that would be returned from a Unix call is returned in
-{\bf status} for IO\_OPEN, IO\_CLOSE, IO\_READ, and IO\_WRITE. The return value for
-IO\_SEEK is returned in {\bf offset} which in general is a 64 bit value.
+The particular Unix function being simulated is indicated by the {\bf func},
+which will have one of the IO\_OPEN, IO\_READ, ... codes listed above. The
+status code that would be returned from a Unix call is returned in {\bf status}
+for IO\_OPEN, IO\_CLOSE, IO\_READ, and IO\_WRITE. The return value for IO\_SEEK
+is returned in {\bf offset} which in general is a 64 bit value.
When there is an error on Unix systems, you must always set io\_error, and
on a Win32 system, you must always set win32, and the returned value from
projects / bacula / docs / commitdiff