+
+A new {\bf Copy} job type 'C' has been implemented. It is similar to the
+existing Migration feature with the exception that the Job that is copied is
+left unchanged. This essentially creates two identical copies of the same
+backup. However, the copy is treated as a copy rather than a backup job, and
+hence is not directly available for restore. The {\bf restore} command lists
+copy jobs and allows selection of copies by using \texttt{jobid=}
+option. If the keyword {\bf copies} is present on the command line, Bacula will
+display the list of all copies for selected jobs.
+
+\begin{verbatim}
+* restore copies
+[...]
+These JobIds have copies as follows:
++-------+------------------------------------+-----------+------------------+
+| JobId | Job | CopyJobId | MediaType |
++-------+------------------------------------+-----------+------------------+
+| 2 | CopyJobSave.2009-02-17_16.31.00.11 | 7 | DiskChangerMedia |
++-------+------------------------------------+-----------+------------------+
++-------+-------+----------+----------+---------------------+------------------+
+| JobId | Level | JobFiles | JobBytes | StartTime | VolumeName |
++-------+-------+----------+----------+---------------------+------------------+
+| 19 | F | 6274 | 76565018 | 2009-02-17 16:30:45 | ChangerVolume002 |
+| 2 | I | 1 | 5 | 2009-02-17 16:30:51 | FileVolume001 |
++-------+-------+----------+----------+---------------------+------------------+
+You have selected the following JobIds: 19,2
+
+Building directory tree for JobId(s) 19,2 ... ++++++++++++++++++++++++++++++++++++++++++++
+5,611 files inserted into the tree.
+...
+\end{verbatim}
+
+
+The Copy Job runs without using the File daemon by copying the data from the
+old backup Volume to a different Volume in a different Pool. See the Migration
+documentation for additional details. For copy Jobs there is a new selection
+criterium named PoolUncopiedJobs which copies all jobs from a pool to an other
+pool which were not copied before. Next to that the client, volume, job or sql
+query are possible ways of selecting jobs which should be copied. Selection
+types like smallestvolume, oldestvolume, pooloccupancy and pooltime are
+probably more suited for migration jobs only. But we could imagine some people
+have a valid use for those kind of copy jobs too.
+
+If bacula founds a copy when a job record is purged (deleted) from the catalog,
+it will promote the copy as \textsl{real} backup and will make it available for
+automatic restore. If more than one copy is available, it will promote the copy
+with the smallest jobid.
+
+A nice solution which can be build with the new copy jobs is what is
+called the disk-to-disk-to-tape backup (DTDTT). A sample config could
+look somethings like the one below:
+
+\begin{verbatim}
+Pool {
+ Name = FullBackupsVirtualPool
+ Pool Type = Backup
+ Purge Oldest Volume = Yes
+ Storage = vtl
+ NextPool = FullBackupsTapePool
+}
+
+Pool {
+ Name = FullBackupsTapePool
+ Pool Type = Backup
+ Recycle = Yes
+ AutoPrune = Yes
+ Volume Retention = 365 days
+ Storage = superloader
+}
+
+#
+# Fake fileset for copy jobs
+#
+Fileset {
+ Name = None
+ Include {
+ Options {
+ signature = MD5
+ }
+ }
+}
+
+#
+# Fake client for copy jobs
+#
+Client {
+ Name = None
+ Address = localhost
+ Password = "NoNe"
+ Catalog = MyCatalog
+}
+
+#
+# Default template for a CopyDiskToTape Job
+#
+JobDefs {
+ Name = CopyDiskToTape
+ Type = Copy
+ Messages = StandardCopy
+ Client = None
+ FileSet = None
+ Selection Type = PoolUncopiedJobs
+ Maximum Concurrent Jobs = 10
+ SpoolData = No
+ Allow Duplicate Jobs = Yes
+ Allow Higher Duplicates = No
+ Cancel Queued Duplicates = No
+ Cancel Running Duplicates = No
+ Priority = 13
+}
+
+Schedule {
+ Name = DaySchedule7:00
+ Run = Level=Full daily at 7:00
+}
+
+Job {
+ Name = CopyDiskToTapeFullBackups
+ Enabled = Yes
+ Schedule = DaySchedule7:00
+ Pool = FullBackupsVirtualPool
+ JobDefs = CopyDiskToTape
+}
+\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 command \texttt{list copies [jobid=x,y,z]} lists copies for a given
+\textbf{jobid}.
+
+\begin{verbatim}
+*list copies
++-------+------------------------------------+-----------+------------------+
+| JobId | Job | CopyJobId | MediaType |
++-------+------------------------------------+-----------+------------------+
+| 9 | CopyJobSave.2008-12-20_22.26.49.05 | 11 | DiskChangerMedia |
++-------+------------------------------------+-----------+------------------+
+\end{verbatim}
+
+\section{ACL Updates}
+\index[general]{ACL Updates}
+The whole ACL code had been overhauled and in this version each platforms has
+different streams for each type of acl available on such an platform. As ACLs
+between platforms tend to be not that portable (most implement POSIX acls but
+some use an other draft or a completely different format) we currently only
+allow certain platform specific ACL streams to be decoded and restored on the
+same platform that they were created on. The old code allowed to restore ACL
+cross platform but the comments already mention that not being to wise. For
+backward compatability the new code will accept the two old ACL streams and
+handle those with the platform specific handler. But for all new backups it
+will save the ACLs using the new streams.
+
+Currently the following platforms support ACLs:
+
+\begin{itemize}
+ \item {\bf AIX}
+ \item {\bf Darwin/OSX}
+ \item {\bf FreeBSD}
+ \item {\bf HPUX}
+ \item {\bf IRIX}
+ \item {\bf Linux}
+ \item {\bf Tru64}
+ \item {\bf Solaris}
+\end{itemize}
+
+Currently we support the following ACL types (these ACL streams use a reserved
+part of the stream numbers):
+
+\begin{itemize}
+\item {\bf STREAM\_ACL\_AIX\_TEXT} 1000 AIX specific string representation from
+ acl\_get
+ \item {\bf STREAM\_ACL\_DARWIN\_ACCESS\_ACL} 1001 Darwin (OSX) specific acl\_t
+ string representation from acl\_to\_text (POSIX acl)
+ \item {\bf STREAM\_ACL\_FREEBSD\_DEFAULT\_ACL} 1002 FreeBSD specific acl\_t
+ string representation from acl\_to\_text (POSIX acl) for default acls.
+ \item {\bf STREAM\_ACL\_FREEBSD\_ACCESS\_ACL} 1003 FreeBSD specific acl\_t
+ string representation from acl\_to\_text (POSIX acl) for access acls.
+ \item {\bf STREAM\_ACL\_HPUX\_ACL\_ENTRY} 1004 HPUX specific acl\_entry
+ string representation from acltostr (POSIX acl)
+ \item {\bf STREAM\_ACL\_IRIX\_DEFAULT\_ACL} 1005 IRIX specific acl\_t string
+ representation from acl\_to\_text (POSIX acl) for default acls.
+ \item {\bf STREAM\_ACL\_IRIX\_ACCESS\_ACL} 1006 IRIX specific acl\_t string
+ representation from acl\_to\_text (POSIX acl) for access acls.
+ \item {\bf STREAM\_ACL\_LINUX\_DEFAULT\_ACL} 1007 Linux specific acl\_t
+ string representation from acl\_to\_text (POSIX acl) for default acls.
+ \item {\bf STREAM\_ACL\_LINUX\_ACCESS\_ACL} 1008 Linux specific acl\_t string
+ representation from acl\_to\_text (POSIX acl) for access acls.
+ \item {\bf STREAM\_ACL\_TRU64\_DEFAULT\_ACL} 1009 Tru64 specific acl\_t
+ string representation from acl\_to\_text (POSIX acl) for default acls.
+ \item {\bf STREAM\_ACL\_TRU64\_DEFAULT\_DIR\_ACL} 1010 Tru64 specific acl\_t
+ string representation from acl\_to\_text (POSIX acl) for default acls.
+ \item {\bf STREAM\_ACL\_TRU64\_ACCESS\_ACL} 1011 Tru64 specific acl\_t string
+ 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)
+\end{itemize}
+
+In future versions we might support conversion functions from one type of acl
+into an other for types that are either the same or easily convertable. For now
+the streams are seperate and restoring them on a platform that doesn't
+recognize them will give you a warning.
+
+\section{Extended Attributes}
+\index[general]{Extended Attributes}
+Something that was on the project list for some time is now implemented for
+platforms that support a similar kind of interface. Its the support for backup
+and restore of so called extended attributes. As extended attributes are so
+platform specific these attributes are saved in seperate streams for each
+platform. Restores of the extended attributes can only be performed on the
+same platform the backup was done. There is support for all types of extended
+attributes, but restoring from one type of filesystem onto an other type of
+filesystem on the same platform may lead to supprises. As extended attributes
+can contain any type of data they are stored as a series of so called
+value-pairs. This data must be seen as mostly binary and is stored as such.
+As security labels from selinux are also extended attributes this option also
+stores those labels and no specific code is enabled for handling selinux
+security labels.
+
+Currently the following platforms support extended attributes:
+\begin{itemize}
+ \item {\bf Darwin/OSX}
+ \item {\bf FreeBSD}
+ \item {\bf Linux}
+ \item {\bf NetBSD}
+\end{itemize}
+
+On linux acls are also extended attributes, as such when you enable ACLs on a
+Linux platform it will NOT save the same data twice e.g. it will save the ACLs
+and not the same exteneded attribute.
+
+To enable the backup of extended attributes please add the following to your
+fileset definition.
+\begin{verbatim}
+ FileSet {
+ Name = "MyFileSet"
+ Include {
+ Options {
+ signature = MD5
+ xattrsupport = yes
+ }
+ File = ...
+ }
+ }
+\end{verbatim}
+
+\section{Shared objects}
+\index[general]{Shared objects}
+A default build of Bacula will now create the libraries as shared objects
+(.so) rather than static libraries as was previously the case.
+The shared libraries are built using {\bf libtool} so it should be quite
+portable.
+
+An important advantage of using shared objects is that on a machine with the
+Directory, File daemon, the Storage daemon, and a console, you will have only
+one copy of the code in memory rather than four copies. Also the total size of
+the binary release is smaller since the library code appears only once rather
+than once for every program that uses it; this results in significant reduction
+in the size of the binaries particularly for the utility tools.
+
+In order for the system loader to find the shared objects when loading the
+Bacula binaries, the Bacula shared objects must either be in a shared object
+directory known to the loader (typically /usr/lib) or they must be in the
+directory that may be specified on the {\bf ./configure} line using the {\bf
+ {-}{-}libdir} option as:
+
+\begin{verbatim}
+ ./configure --libdir=/full-path/dir
+\end{verbatim}
+
+the default is /usr/lib. If {-}{-}libdir is specified, there should be
+no need to modify your loader configuration provided that
+the shared objects are installed in that directory (Bacula
+does this with the make install command). The shared objects
+that Bacula references are:
+
+\begin{verbatim}
+libbaccfg.so
+libbacfind.so
+libbacpy.so
+libbac.so
+\end{verbatim}
+
+These files are symbolically linked to the real shared object file,
+which has a version number to permit running multiple versions of
+the libraries if desired (not normally the case).
+
+If you have problems with libtool or you wish to use the old
+way of building static libraries, or you want to build a static
+version of Bacula you may disable
+libtool on the configure command line with:
+
+\begin{verbatim}
+ ./configure --disable-libtool
+\end{verbatim}
+
+
+\section{Building Static versions of Bacula}
+\index[general]{Static linking}
+In order to build static versions of Bacula, in addition
+to configuration options that were needed you now must
+also add --disable-libtool. Example
+
+\begin{verbatim}
+ ./configure --enable-static-client-only --disable-libtool
+\end{verbatim}
+