From: Kern Sibbald Date: Mon, 24 Mar 2014 11:54:13 +0000 (+0100) Subject: Add more new features X-Git-Tag: Release-7.0.0~6 X-Git-Url: https://git.sur5r.net/?p=bacula%2Fdocs;a=commitdiff_plain;h=76ed035d83ff44a97b0bae08c3b3c88153d555c1 Add more new features --- diff --git a/docs/manuals/en/main/newfeatures.tex b/docs/manuals/en/main/newfeatures.tex index 433c0381..8a56579e 100644 --- a/docs/manuals/en/main/newfeatures.tex +++ b/docs/manuals/en/main/newfeatures.tex @@ -25,6 +25,77 @@ both cases. \includegraphics[width=0.8\linewidth]{sd-calls-client} +\subsection{Next Pool} +In previous versions of Bacula the Next Pool directive could be +specified in the Pool resource for use with Migration and Copy Jobs. +The Next Pool concept has been +extended in Bacula version 7.0.0 to allow you to specify the +Next Pool directive in the Job resource as well. If specified in +the Job resource, it will override any value specified in the Pool +resource. + +In addition to being permitted in the Job resource, the +{\bf nextpool=xxx) specification can be specified as a run +override in the {\bf run} directive of a Schedule resource. +Any {\bf nextpool} specification in a {\bf run} +directive will override any other specification in either +the Job or the Pool. + +In general, more information is displayed in the Job log +on exactly which Next Pool specification is ultimately used. + +\subsection{status schedule} +A new status command option called {\bf scheduled} has been implemented +in bconsole. By default it will display 20 lines of the next scheduled +jobs. For example, with the default bacula-dir.conf configuration file, +a bconsole command {\bf status scheduled} produces: + +\begin{verbatim} +Scheduled Jobs: +Level Type Pri Scheduled Job Name Schedule +====================================================================== +Differential Backup 10 Sun 30-Mar 23:05 BackupClient1 WeeklyCycle +Incremental Backup 10 Mon 24-Mar 23:05 BackupClient1 WeeklyCycle +Incremental Backup 10 Tue 25-Mar 23:05 BackupClient1 WeeklyCycle +Incremental Backup 10 Wed 26-Mar 23:05 BackupClient1 WeeklyCycle +Incremental Backup 10 Thu 27-Mar 23:05 BackupClient1 WeeklyCycle +Incremental Backup 10 Fri 28-Mar 23:05 BackupClient1 WeeklyCycle +Incremental Backup 10 Sat 29-Mar 23:05 BackupClient1 WeeklyCycle +Incremental Backup 10 Mon 31-Mar 23:05 BackupClient1 WeeklyCycle +Incremental Backup 10 Tue 01-Apr 23:05 BackupClient1 WeeklyCycle +Incremental Backup 10 Wed 02-Apr 23:05 BackupClient1 WeeklyCycle +Full Backup 11 Mon 24-Mar 23:10 BackupCatalog WeeklyCycleAfterBackup +Full Backup 11 Tue 25-Mar 23:10 BackupCatalog WeeklyCycleAfterBackup +Full Backup 11 Wed 26-Mar 23:10 BackupCatalog WeeklyCycleAfterBackup +Full Backup 11 Thu 27-Mar 23:10 BackupCatalog WeeklyCycleAfterBackup +Full Backup 11 Fri 28-Mar 23:10 BackupCatalog WeeklyCycleAfterBackup +Full Backup 11 Sat 29-Mar 23:10 BackupCatalog WeeklyCycleAfterBackup +Full Backup 11 Sun 30-Mar 23:10 BackupCatalog WeeklyCycleAfterBackup +Full Backup 11 Mon 31-Mar 23:10 BackupCatalog WeeklyCycleAfterBackup +Full Backup 11 Tue 01-Apr 23:10 BackupCatalog WeeklyCycleAfterBackup +Full Backup 11 Wed 02-Apr 23:10 BackupCatalog WeeklyCycleAfterBackup +==== +\end{verbatim} + +Note, the output is listed by the Jobs found, and is not sorted +chronologically. + +This command has a number of options, most of which act as filters: +\begin{itemize} +\item {\bf days=nn} This specifies the number of days to list. The default is + 10 but can be set from 0 to 500. +\item {\bf limit=nn} This specifies the limit to the number of lines to print. + The default is 100 but can be any number in the range 0 to 2000. +\item {\bf time="YYYY-MM-DD HH:MM:SS"} Sets the start time for listing the + scheduled jobs. The default is to use the current time. Note, the + time value must be specified inside double quotes and must be in + the exact form shown above. +\item {\bf schedule=schedule-name} This option restricts the output to + the named schedule. +\item {\bf job=job-name} This option restricts the output to the specified + Job name. +\end{itemize} + \subsection{Data Encryption Cipher Configuration} Bacula version 7.0 and later now allows to configure the data encryption cipher and the digest algorithm. The cipher was forced to AES @@ -325,6 +396,80 @@ definition. } \end{verbatim} +\subsection{Hardlink Performance Enhancements} +If you use a program such as Cyrus IMAP that creates very large numbers +of hardlinks, the time to build the interactive restore tree can be +excessively long. This version of Bacula has a new feature that +automatically keeps the hardlinks associated with the restore tree +in memory, which consumes a bit more memory but vastly speeds up +building the tree. If the memory usage is too big for your system, you +can reduce the amount of memory used during the restore command by +adding the option {\bf optimizespeed=false} on the bconsole run +command line. + +This feature was developed by Josip Almasi, and enhanced to be runtime +dynamic by Kern Sibbald. + +\subsection{Multiple Console Directors} +Support for multiple bconsole and bat Directors in the bconsole.conf and +bat.conf files has been implemented and/or improved. + +\subsection{Restricted Consoles} +Better support for Restricted consoles has been implement for bconsole and +bat. + +\subsection{Configuration Files} +In previous versions of Bacula the configuration files for each component +were limited to a maximum of 499 bytes per configuration file line. This +version of Bacula permits unlimited input line lengths. This can be +especially useful for specifying more complicated Migration/Copy SQL +statements and in creating long restricted console ACL lists. + +\subsection{Maximum Spawned Jobs} +The Job resource now permits specifing a number of {\bf Maximum Spawn +Jobs}. The default is 300. This directive can be useful if you have +big hardware and you do a lot of Migration/Copy jobs which start +at the same time. In prior versions of Bacula, Migration/Copy +was limited to spawning a maximum of 100 jobs at a time. + +\subsection{Progress Meter} +The new File daemon has been enhanced to send its progress (files +processed and bytes written) to the Director every 30 seconds. These +figures can then be displayed with a bconsole {\bf status dir} +command. + +\subsection{Scheduling a 6th Week} +Prior version of Bacula permits specifying 1st through 5th week of +a month (first through fifth) as a keyword on the {\bf run} +directive of a Schedule resource. This version of Bacula also permits +specifying the 6th week of a month with the keyword {\bf sixth} or +{\bf 6th}. + +\subsection{Secheduling the Last Day of a Month} +This version of Bacula now premits specifying the {\bf lastday} +keyword in the {\bf run} directive of a Schedule resource. +If {\bf lastday} is specified, it will apply only to those months +specified on the {\bf run} directive. Note: by default all months +are specified. + +\subsection{Improvements to Cancel and Restart bconsole Commands} +The Restart bconsole command now allow selection of either +canceled or failed jobs to be restarted. In addition both the +{\bf cancel} and {\bf restart} bconsole commands permit entering +a number of JobIds separated by commas or a range of JobIds indicated +by a dash between the begin and end range (e.g. 3-10). Finally the +two commands also allow one to enter the special keyword {\bf all} +to select all the appropriate Jobs. + +\subsection{bconsole Performance Improvements} +In previous versions of Bacula certain bconsole commands could wait a long +time due to catalog lock contention. This was especially noticable +when a large number of jobs were running and putting their attributes +into the catalog. This version uses a separate catalog connection that +should significantly enhance performance. + + + \subsection*{New Debug Options}