]> git.sur5r.net Git - bacula/docs/blobdiff - docs/manuals/en/main/newfeatures.tex
Add notes on Maximum Bandwidth
[bacula/docs] / docs / manuals / en / main / newfeatures.tex
index d90350a78091912d29671461c99cfc380a9857d7..d78e4a409682b41596ada4a6080d23dc7b071c4f 100644 (file)
@@ -3,6 +3,362 @@ This chapter presents the new features that have been added to the
 current version of Bacula that is under development. This version will be
 released at some later date, probably near the end of 2010.
 
+\section{Job Bandwidth Limitation}
+
+A new directive may be added to FileDaemon or Director resources within the
+File Daemon configuration to allow users to limit the bandwidth used by a
+Job on a Client. It can be set for all Jobs globally or per Directors.
+
+For example:
+\begin{verbatim}
+FileDaemon {
+  Name = localhost-fd
+  Working Directory = /some/path
+  Pid Directory = /some/path
+  ...
+  Maximum Bandwidth = 5MB/s
+}
+\end{verbatim}
+
+The above example would cause any jobs running with the FileDaemon to not
+exceed 5MB/s of throughput when sending data to the Storage Daemon.
+
+You can specify the speed parameter in k/s, kb/s, m/s, mb/s.
+
+This project was funded by Bacula Systems and is available with Bacula
+Enterprise Edition and Community Edition.
+
+\section{Support for MSSQL Block Level Backup}
+
+This project was funded by Bacula Systems and is available with Bacula
+Enterprise Edition.
+
+\section{Support for NDMP protocol}
+
+The new \texttt{ndmp} Plugin is able to backup a NAS through NDMP protocol
+using \textbf{Filer to server} approach, where the Filer is backing up across
+the LAN to your Bacula server.
+
+Accurate option should be turned on in the Job resource.
+\begin{verbatim}
+Job {
+ Accurate = yes
+ FileSet = NDMPFS
+ ...
+}
+
+FileSet {
+ Name = NDMPFS
+ ...
+ Include {
+   Plugin = "ndmp:host=nasbox user=root pass=root file=/vol/vol1"
+ }
+}
+\end{verbatim}
+
+This project was funded by Bacula Systems and is available with Bacula Enterprise
+Edition.
+
+\section{Incremental/Differential Block Level Difference Backup}
+
+The new \texttt{delta} Plugin is able to compute and apply signature-based file
+differences. It can be used to backup only changes in a big binary file like Outlook
+PST, VirtualBox/VmWare images or database files.
+
+It supports both Incremental and Differential backups and stores signatures
+database in the File Daemon working directory. This plugin is available on all
+plateform including Windows 32 and 64bit.
+
+Accurate option should be turned on in the Job resource.
+\begin{verbatim}
+Job {
+ Accurate = yes
+ FileSet = DeltaFS
+ ...
+}
+
+FileSet {
+ Name = DeltaFS
+ ...
+ Include {
+   Plugin = "delta:/home/eric/.VirtualBox/HardDisks/lenny-i386.vdi"
+ }
+}
+\end{verbatim}
+
+This project was funded by Bacula Systems and is available with Bacula Enterprise
+Edition.
+
+\section{Include All Windows Drives in FileSet}
+
+The \texttt{alldrives} Windows Plugin allows you to include all local drives with
+a simple directive. This plugin is available for Windows 64 and 32 bit.
+
+\begin{verbatim}
+FileSet {
+ Name = EverythingFS
+ ...
+ Include {
+   Plugin = "alldrives"
+ }
+}
+\end{verbatim}
+
+This project was funded by Bacula Systems and is available with Bacula Enterprise
+Edition.
+
+\section{Changes in Bvfs (Bacula Virtual FileSystem)}
+
+Bat has now a bRestore panel that uses Bvfs to display files and
+directories. It's still experimental.
+
+\texttt{Important}, the Bvfs module is not currently compatible with BaseJobs,
+Copy and Migration jobs.
+
+\subsection*{General notes}
+
+\begin{itemize}
+\item All fields are separated by a tab
+\item You can specify \texttt{limit=} and \texttt{offset=} to list smoothly
+  records in very big directories
+\item All operations (except cache creation) are designed to run instantly
+\item At this time, Bvfs works faster on PostgreSQL than MySQL catalog. If you
+  can contribute new faster SQL queries we will be happy, else don't complain
+  about speed.
+\item The cache creation is dependent of the number of directories. As Bvfs
+  shares information accross jobs, the first creation can be slow
+\item All fields are separated by a tab
+\item Due to potential encoding problem, it's advised to allways use pathid in
+  queries.
+\end{itemize}
+
+\subsection*{Get dependent jobs from a given JobId}
+
+Bvfs allows you to query the catalog against any combination of jobs. You
+can combine all Jobs and all FileSet for a Client in a single session.
+
+To get all JobId needed to restore a particular job, you can use the
+\texttt{.bvfs_get_jobids} command.
+
+\begin{verbatim}
+.bvfs_get_jobids jobid=num [all]
+\end{verbatim}
+
+\begin{verbatim}
+.bvfs_get_jobids jobid=10
+1,2,5,10
+.bvfs_get_jobids jobid=10 all
+1,2,3,5,10
+\end{verbatim}
+
+In this example, a normal restore will need to use JobIds 1,2,5,10 to
+compute a complete restore of the system.
+
+With the \texttt{all} option, the Director will use all defined FileSet for
+this client.
+
+\subsection*{Generating Bvfs cache}
+
+The \texttt{.bvfs_update} command computes the directory cache for jobs
+specified in argument, or for all jobs if unspecified.
+
+\begin{verbatim}
+.bvfs_update [jobid=numlist]
+\end{verbatim}
+
+Example:
+\begin{verbatim}
+.bvfs_update jobid=1,2,3
+\end{verbatim}
+
+You can run the cache update process in a RunScript after the catalog backup.
+
+\subsection*{Get all versions of a specific file}
+
+Bvfs allows you to find all versions of a specific file for a given Client with
+the \texttt{.bvfs_version} command. To avoid problems with encoding, this function
+uses only PathId and FilenameId. The jobid argument is mandatory but unused.
+
+\begin{verbatim}
+.bvfs_versions client=filedaemon pathid=num filenameid=num jobid=1
+PathId FilenameId FileId JobId LStat Md5 VolName Inchanger
+PathId FilenameId FileId JobId LStat Md5 VolName Inchanger
+...
+\end{verbatim}
+
+Example:
+
+\begin{verbatim}
+.bvfs_versions client=localhost-fd pathid=1 fnid=47 jobid=1
+1  47  52  12  gD HRid IGk D Po Po A P BAA I A   /uPgWaxMgKZlnMti7LChyA  Vol1  1
+\end{verbatim}
+
+\subsection*{List directories}
+
+Bvfs allows you to list directories in a specific path.
+\begin{verbatim}
+.bvfs_lsdirs pathid=num path=/apath jobid=numlist limit=num offset=num
+PathId  FilenameId  FileId  JobId  LStat  Path
+PathId  FilenameId  FileId  JobId  LStat  Path
+PathId  FilenameId  FileId  JobId  LStat  Path
+...
+\end{verbatim}
+
+You need to \texttt{pathid} or \texttt{path}. Using \texttt{path=""} will list
+``/'' on Unix and all drives on Windows.  If FilenameId is 0, the record
+listed is a directory.
+
+\begin{verbatim}
+.bvfs_lsdirs pathid=4 jobid=1,11,12
+4       0       0       0       A A A A A A A A A A A A A A     .
+5       0       0       0       A A A A A A A A A A A A A A     ..
+3       0       0       0       A A A A A A A A A A A A A A     regress/
+\end{verbatim}
+
+In this example, to list directories present in \texttt{regress/}, you can use
+\begin{verbatim}
+.bvfs_lsdirs pathid=3 jobid=1,11,12
+3       0       0       0       A A A A A A A A A A A A A A     .
+4       0       0       0       A A A A A A A A A A A A A A     ..
+2       0       0       0       A A A A A A A A A A A A A A     tmp/
+\end{verbatim}
+
+\subsection*{List files}
+
+Bvfs allows you to list files in a specific path.
+\begin{verbatim}
+.bvfs_lsfiles pathid=num path=/apath jobid=numlist limit=num offset=num
+PathId  FilenameId  FileId  JobId  LStat  Path
+PathId  FilenameId  FileId  JobId  LStat  Path
+PathId  FilenameId  FileId  JobId  LStat  Path
+...
+\end{verbatim}
+
+You need to \texttt{pathid} or \texttt{path}. Using \texttt{path=""} will list
+``/'' on Unix and all drives on Windows. If FilenameId is 0, the record listed
+is a directory.
+
+\begin{verbatim}
+.bvfs_lsfiles pathid=4 jobid=1,11,12
+4       0       0       0       A A A A A A A A A A A A A A     .
+5       0       0       0       A A A A A A A A A A A A A A     ..
+1       0       0       0       A A A A A A A A A A A A A A     regress/
+\end{verbatim}
+
+In this example, to list files present in \texttt{regress/}, you can use
+\begin{verbatim}
+.bvfs_lsfiles pathid=1 jobid=1,11,12
+1   47   52   12    gD HRid IGk BAA I BMqcPH BMqcPE BMqe+t A     titi
+1   49   53   12    gD HRid IGk BAA I BMqe/K BMqcPE BMqe+t B     toto
+1   48   54   12    gD HRie IGk BAA I BMqcPH BMqcPE BMqe+3 A     tutu
+1   45   55   12    gD HRid IGk BAA I BMqe/K BMqcPE BMqe+t B     ficheriro1.txt
+1   46   56   12    gD HRie IGk BAA I BMqe/K BMqcPE BMqe+3 D     ficheriro2.txt
+\end{verbatim}
+
+\subsection*{Restore set of files}
+
+Bvfs allows you to create a SQL table that contains files that you want to
+restore. This table can be provided to a restore command with the file option.
+
+\begin{verbatim}
+.bvfs_restore fileid=numlist dirid=numlist hardlink=numlist path=b2num
+OK
+restore file=?b2num ...
+\end{verbatim}
+
+To include a directory (with \texttt{dirid}), Bvfs needs to run a query to
+select all files. This query could be time consuming.
+
+\texttt{hardlink} list is always composed of a serie of two numbers (jobid,
+fileindex). This information can be found in the LinkFI field of the LStat
+packet.
+
+The \texttt{path} argument represents the name of the table that Bvfs will
+store results. The format of this table is \texttt{b2[0-9]+}. (Should start by
+b2 and followed by digits).
+
+Example:
+
+\begin{verbatim}
+.bvfs_restore fileid=1,2,3,4 hardlink=10,15,10,20 jobid=10 path=b20001
+OK
+\end{verbatim}
+
+\subsection*{Cleanup after restore}
+
+To drop the table used by the restore command, you can use the
+\texttt{.bvfs_cleanup} command.
+
+\begin{verbatim}
+.bvfs_cleanup path=b20001
+\end{verbatim}
+
+\section{Changes in the pruning algorithm}
+
+We rewrote the job pruning algorithm in this version. Previously, in some users
+reported that the pruning process at the end of jobs was very long. It should
+not be longer the case. Now, Bacula won't prune automatically a Job if this
+particular Job is needed to restore data. Example:
+
+\begin{verbatim}
+JobId: 1  Level: Full
+JobId: 2  Level: Incremental
+JobId: 3  Level: Incremental
+JobId: 4  Level: Differential
+.. Other incrementals up to now
+\end{verbatim}
+
+In this example, if the Job Retention defined in the Pool or in the Client
+resource causes that Jobs with Jobid in 1,2,3,4 can be pruned, Bacula will
+detect that JobId 1 and 4 are essential to restore data at the current state
+and will prune only JobId 2 and 3.
+
+\texttt{Important}, this change affect only the automatic pruning step after a
+Job and the \texttt{prune jobs} Bconsole command. If a volume expires after the
+\texttt{VolumeRetention} period, important jobs can be pruned.
+
+\section{Ability to Verify any specified Job}
+You now have the ability to tell Bacula which Job should verify instead of
+automatically verify just the last one.
+
+This feature can be used with VolumeToCatalog, DiskToCatalog and Catalog level.
+
+To verify a given job, just specify the Job jobid in argument when starting the
+job.
+\begin{verbatim}
+*run job=VerifyVolume jobid=1 level=VolumeToCatalog
+Run Verify job
+JobName:     VerifyVolume
+Level:       VolumeToCatalog
+Client:      127.0.0.1-fd
+FileSet:     Full Set
+Pool:        Default (From Job resource)
+Storage:     File (From Job resource)
+Verify Job:  VerifyVol.2010-09-08_14.17.17_03
+Verify List: /tmp/regress/working/VerifyVol.bsr
+When:        2010-09-08 14:17:31
+Priority:    10
+OK to run? (yes/mod/no):
+\end{verbatim}
+
+\section{Additions to RunScript variables}
+You can have access to JobBytes and JobFiles using %b and %f in your runscript
+command.
+
+\begin{verbatim}
+RunAfterJob = "/bin/echo Job=%j JobBytes=%b JobFiles=%f"
+\end{verbatim}
+
+\section{Changes in drivetype.exe}
+
+Now the \texttt{drivetype.exe} program allows you to list all local hard
+drives. It can help to build dynamic FileSet on Windows.
+
+\begin{verbatim}
+File = "\\|\"c:/program files/bacula/bin32/drivetype\" -l -a"
+\end{verbatim}
+
+
 \section{Additions to the Plugin API}
 The bfuncs structure has been extended to include a number of
 new entrypoints.
@@ -163,6 +519,17 @@ typedef enum {
 \end{description}
 
 
+\chapter{Release Version 5.0.3}
+
+There are no new features in version 5.0.2.  This version simply fixes a
+number of bugs found in version 5.0.1 during the onging development
+process.
+
+\chapter{Release Version 5.0.2}
+
+There are no new features in version 5.0.2.  This version simply fixes a
+number of bugs found in version 5.0.1 during the onging development
+process.
 
 %%
 %%
@@ -317,7 +684,7 @@ FileSet {
   Include = {
     Options {
        BaseJob  = pmugcs5
-       Accurate = mcs5
+       Accurate = mcs
        Verify   = pin5
     }
     File = /
@@ -372,7 +739,7 @@ FileSet {
   Name = Full
   Include = {
     Options {
-       Accurate = mcs5
+       Accurate = mcs
        Verify   = pin5
     }
     File = /
@@ -421,15 +788,24 @@ The new bconsole won't be able to tab-complete with older directors.
 
 This project was funded by Bacula Systems.
 
-\section{Pool File and Job retention}
+\section{Pool File and Job Retention}
 \label{sec:poolfilejobretention}
 
-% TODO check
 We added two new Pool directives, \texttt{FileRetention} and
 \texttt{JobRetention}, that take precedence over Client directives of the same
 name. It allows you to control the Catalog pruning algorithm Pool by Pool. For
 example, you can decide to increase Retention times for Archive or OffSite Pool.
 
+It seems obvious to us, but apparently not to some users, that given the
+definition above that the Pool File and Job Retention periods is a global
+override for the normal Client based prunning, which means that when the
+Job is prunned, the prunning will apply globally to that particular Job.
+
+Currently, there is a bug in the implementation that causes any Pool 
+retention periods specified to apply to {\bf all} Pools for that
+particular Client.  Thus we suggest that you avoid using these two
+directives until this implementation problem is corrected.
+
 \section{Read-only File Daemon using capabilities}
 \label{sec:fdreadonly}
 This feature implements support of keeping \textbf{ReadAll} capabilities after
@@ -1642,6 +2018,9 @@ plugin.
 The {\bf bpipe} plugin is provided in the directory src/plugins/fd/bpipe-fd.c of
 the Bacula source distribution. When the plugin is compiled and linking into
 the resulting dynamic shared object (DSO), it will have the name {\bf bpipe-fd.so}.
+Please note that this is a very simple plugin that was written for
+demonstration and test purposes. It is and can be used in production, but
+that was never really intended.
 
 The purpose of the plugin is to provide an interface to any system program for
 backup and restore. As specified above the {\bf bpipe} plugin is specified in
@@ -1669,13 +2048,24 @@ a conflict with a path and filename that actually exists on your system.
 \item {\bf field3} for the {\bf bpipe} plugin 
 specifies the "reader" program that is called by the plugin during
 backup to read the data. {\bf bpipe} will call this program by doing a
-{\bf popen} on it.
+{\bf popen} on it. 
 
 \item {\bf field4} for the {\bf bpipe} plugin
 specifies the "writer" program that is called by the plugin during
 restore to write the data back to the filesystem.  
 \end{description}
 
+Please note that for two items above describing the "reader" and "writer"
+fields, these programs are "executed" by Bacula, which
+means there is no shell interpretation of any command line arguments
+you might use.  If you want to use shell characters (redirection of input
+or output, ...), then we recommend that you put your command or commands
+in a shell script and execute the script. In addition if you backup a
+file with the reader program, when running the writer program during
+the restore, Bacula will not automatically create the path to the file.
+Either the path must exist, or you must explicitly do so with your command
+or in a shell script.
+
 Putting it all together, the full plugin directive line might look
 like the following: