\index[sd]{Resource!Autochanger }
\addcontentsline{toc}{subsection}{Autochanger Resource}
-The Autochanger resource serves to group one or more Device resources
-into one unit called an autochanger in Bacula (referred to
-as a tape library by autochanger manufacturers).
+The Autochanger resource supports single or multiple drive
+autochangers by grouping one or more Device resources
+into one unit called an autochanger in Bacula (often referred to
+as a ``tape library´´ by autochanger manufacturers).
\begin{description}
\item [Name = \lt{}Autochanger-Name\gt{}]
This directive is required.
\item [Device = \lt{}Device-name1, device-name2, ...\gt{}]
- Specifies the names of the Device resource that corresponds
+ Specifies the names of the Device resource or
+ resources that correspond
to the autochanger drive. If you have a multiple drive
autochanger, you must specify multiple Device names, each
- one referring to a Device resource that contains a the
+ one referring to a separate Device resource that contains a the
Drive Index specification that corresponds to the drive
number. You may specify multiple device names on
a single line separated by commas, and/or you may specify
\begin{verbatim}
Autochanger {
Name = "DDS-4-changer"
- Device = DDS-4-1, DDS-4-2
+ Device = DDS-4-1, DDS-4-2, DDS-4-3
Changer Device = /dev/sg0
Changer Command = "/etc/bacula/mtx-changer %c %o %S %a %d"
}
Device {
Name = "DDS-4-1"
Drive Index = 0
+ Autochanger = yes
...
}
Device {
Name = "DDS-4-2"
Drive Index = 1
+ Autochanger = yes
+ ...
+Device {
+ Name = "DDS-4-3"
+ Drive Index = 2
+ Autochanger = yes
+ Autoselect = no
...
}
\end{verbatim}
\normalsize
+
+Please note that it is important to include the {\bf Autochanger = yes} directive
+in each Device definition that belongs to an Autochanger. A device definition
+should not belong to more than one Autochanger resource.
+
+If you have a drive that physically belongs to an Autochanger but you don't want
+to have it automatically used when Bacula references the Autochanger for backups,
+for example, you want to reserve it for restores, you can add the directive:
+
+\footnotesize
+\begin{verbatim}
+Autoselect = no
+\end{verbatim}
+\normalsize
+
+to the Device resource for that drive. In that case, Bacula will not automatically
+select that drive when accessing the Autochanger. You can, still use the drive
+by referencing it by the Device name rather than the Autochanger name. An example
+of such a definition is shown above for the Device DDS-4-3, which will not be
+selected when the name DDS-4-changer is used in a Storage definition, but will
+be used if DDS-4-3 is used.
All database programs have some means of writing the database out in ASCII
format and then reloading it. Doing so will re-create the database from
scratch producing a compacted result, so below, we show you how you can do
-this for both MySQL and SQLite.
+this for MySQL, PostgreSQL and SQLite.
For a {\bf MySQL} database, you could write the Bacula database as an ASCII
file (bacula.sql) then reload it by doing the following:
the errors that are generated by the DDL statements that SQLite's dump
creates. Of course, you could edit the dump and remove the offending
statements. Otherwise, MySQL accepts the SQL produced by SQLite.
-\label{BackingUpBacula}
+\label{BackingUpBacula}
\subsection*{Backing Up Your Bacula Database}
\index[general]{Backing Up Your Bacula Database }
\index[general]{Database!Backing Up Your Bacula }
Pool = Default
RunBeforeJob = "/home/kern/bacula/bin/make_catalog_backup"
RunAfterJob = "/home/kern/bacula/bin/delete_catalog_backup"
+ Write Bootstrap = "/home/kern/bacula/working/BackupCatalog.bsr"
}
# This schedule does the catalog. It starts after the WeeklyCycle
Schedule {
\end{verbatim}
\normalsize
-\label{BackingUPOtherDBs}
+Be sure to write a bootstrap file as in the above example. It is preferable
+to write or copy the bootstrap file to another computer. It will allow
+you to quickly recover the database backup should that be necessary. If
+you do not have a bootstrap file, it is still possible to recover your
+database backup, but it will be more work and take longer.
+\label{BackingUPOtherDBs}
\subsection*{Backing Up Third Party Databases}
\index[general]{Backing Up Third Party Databases }
\index[general]{Databases!Backing Up Third Party }
Device resource, under most circumstances, Bacula will automatically access
the Volume unless you have explicitly {\bf unmount}ed it in the Console
program.
-\label{ManualPruning}
+\item[python]
+ \index[console]{python}
+ The python command takes a slingle argument {\bf restart}:
+
+python restart
+
+ This causes the Python interpreter in the Director to be
+ reinitialized. This can be helpful for testing because once
+ the Director starts and the Python interpreter is initialized,
+ there is no other way to make it accept any changes to the
+ startup script {\bf DirStartUp.py}. For more details on
+ Python scripting, please see the \ilink{Python Scripting}{_ChapterStart60}
+ chapter of this manual.
+
+\label{ManualPruning}
\item [prune]
\index[console]{prune }
The Prune command allows you to safely remove expired database records from
10 prior set of configurations before it will refuse a reload
command. Once at least one old set of config values has been
released it will again accept new reload commands.
-
-
+
+
\item [restore]
\index[console]{restore }
The restore command allows you to select one or more Jobs (JobIds) to be
files from the catalog during an Incremental backup is quite a time consuming
process and not currently implemented in Bacula.
+In addition, if you move a directory rather than copy it, the files in it do not
+have their modification time (st\_mtime) or their attribute change time (st\_ctime)
+changed. As a conseqence, those files will probably not be backed up by an Incremental
+or Differential backup which depend solely on these time stamps. If you move a directory,
+and which it to be properly backed up, it is generally preferable to copy it then
+delete the original.
+
\item [Differential]
\index[dir]{Differential }
is all files that have changed since the last successful Full backup of the
The File daemon (Client) decides which files to backup for a differential
backup by comparing the start time of the prior Full backup Job against the
time each file was last ``modified'' (st\_mtime) and the time its attributes
-were last ``changed''(st\_ctime). If the file was modified or its attributs
-were changed on or after this start time, it will then be backed up. The
+were last ``changed'' (st\_ctime). If the file was modified or its attributes
+were changed on or after this start time, it will then be backed up. The
start time used is displayed after the {\bf Since} on the Job report. In rare
cases, using the start time of the prior backup may cause some files to be
backed up twice, but it ensures that no change is missed. As with the
a Full save and the time you do a restore, some files are deleted, those
deleted files will also be restored. The deleted files will no longer appear
in the catalog after doing another Full save. However, to remove deleted
-files from the catalog during a Differential backup is quite a time consuming
+files from the catalog during a Differential backup is quite a time consuming
process and not currently implemented in Bacula.
+
+As noted above, if you move a directory rather than copy it, the files in it do not
+have their modification time (st\_mtime) or their attribute change time (st\_ctime)
+changed. As a conseqence, those files will probably not be backed up by an Incremental
+or Differential backup which depend solely on these time stamps. If you move a directory,
+and which it to be properly backed up, it is generally preferable to copy it then
+delete the original.
\end{description}
For a {\bf Restore} Job, no level needs to be specified.
\item [Pool = \lt{}pool-resource-name\gt{}]
\index[dir]{Pool }
- The Pool directive defines the pool of Volumes where your data can be backed
+ The Pool directive defines the pool of Volumes where your data can be backed
up. Many Bacula installations will use only the {\bf Default} pool. However,
if you want to specify a different set of Volumes for different Clients or
different Jobs, you will probably want to use Pools. For additional details,
the same as when the job was scheduled). Please note that if there is a
{\bf Max Wait Time} it may also be applied to the job.
+\item [Prefer Mounted Volumes = \lt{}yes|no\gt{}]
+ \index[dir]{Prefer Mounted Volumes}
+ It the Prefer Mounted Volumes directive is set to {\bf yes}
+ (default yes), it is used to inform the Storage daemon
+ to select either an Autochanger or a drive with a valid
+ Volume already mounted in preference to a drive that is
+ not ready. If none is available, it will select the first
+ available drive. If the directive is set to {\bf no}, the
+ Storage daemon will prefer finding an unused drive. This
+ can potentially be useful for those sites that prefer to
+ maximum backup throughput at the expense of using additional
+ drives and Volumes.
+
+
\item [Prune Jobs = \lt{}yes|no\gt{}]
\index[dir]{Prune Jobs }
Normally, pruning of Jobs from the Catalog is specified on a Client by
job. If it is set to zero (the default) the job will be rescheduled an
indefinite number of times.
+\item [Run = \lt{}job-name\gt{}]
+ \index[dir]{Run directive}
+ \index[dir]{Clone a Job}
+ The Run directive (not to be confused with the Run option in a
+ Schedule) allows you to clone jobs and thus, if you want backup
+ the same data (or almost the same data) to two or more drives
+ at the same time. The {\bf job-name} is normally the same name
+ as the current Job resource (thus creating a clone). However, it
+ may be any Job name, so one job may start other related jobs.
+
+ The part after the equal sign must be enclosed in double quotes,
+ and can contain any string or set of options (overrides) that you
+ can specify when entering the Run command from the console. For
+ example {\bf storage=DDS-4 ...}. In addition, there are two special
+ keywords that permit you to clone the current job. They are {\bf level=\%l}
+ and {\bf since=\%s}. The \%l in the level keyword permits
+ entering the actual level of the current job and the \%s in the since
+ keyword permits putting the same time for comparison as used on the
+ current job. Note, in the case of the since keyword, the \%s must be
+ enclosed in double quotes, and thus they must be preceded by a backslash
+ since they are already inside quotes. For example:
+
+\begin{verbatim}
+ run = "Nightly-backup level=%s since=\"%s\" storage=DDS-4"
+\end{verbatim}
+
+
+ A cloned job will not start additional clones, so it is not
+ possible to recurse.
+
+
+
\label{Priority}
\item [Priority = \lt{}number\gt{}]
\index[dir]{Priority }
\ilink{Backup Strategies}{_ChapterStart3} chapter of this
manual.
+
To use a Pool, there are three distinct steps. First the Pool must be defined
in the Director's configuration file. Then the Pool must be written to the
Catalog database. This is done automatically by the Director each time that it
\end{verbatim}
\normalsize
+\subsubsection*{The Scratch Pool}
+\addcontentsline{toc}{subsection}{Scratch Pool}
+\index[general]{Scratch Pool}
+In general, you can give your Pools any name you wish, but there is one
+important restriction: the Pool named {\bf Scratch}, if it exists behaves
+like a scratch pool of Volumes in that when Bacula needs a new Volume for
+writing and it cannot find one, it will look in the Scratch pool, and if
+it finds an available Volume, it will move it out of the Scratch pool into
+the Pool currently being used by the job.
+
+
\subsection*{The Catalog Resource}
\label{CatalogResource}
\index[general]{Resource!Catalog }
The name of the FileSet resource. This directive is required.
\item [Ignore FileSet Changes = \lt{}yes|no\gt{}]
-\index[dir]{Ignore FileSet Changes }
+\index[dir]{Ignore FileSet Changes}
If this directive is set to {\bf yes}, any changes you make to the FileSet
Include or Exclude lists will be ignored and not cause Bacula to immediately
perform a Full backup. The default is {\bf no}, in which case, if you change
everything is properly backed up. It is not recommended to set this directive
to yes. This directive is available in Bacula version 1.35.4 or later.
+\item [Enable VSS = \lt{}yes|no\gt{}]
+\index[dir]{Enable VSS}
+ If this directive is set to {\bf yes} the File daemon will be notified
+ that the user wants to use a Volume Shadow Copy Service (VSS) backup
+ for this job. The default is {\bf no}. This directive is effective
+ only for VSS enabled Win32 File daemons. It permits a consistent copy
+ of open files to be made for cooperating writer applications, and for
+ applications that are not VSS away, Bacula can at least copy open files.
+ For more information, please see the
+ \ilink{Windows}{VSS} chapter of this manual.
+
\item [Include \{ Options \{\lt{}file-options\gt{}\} ...;
\lt{}file-list\gt{} \} ]
-\index[dir]{Include \ \{ [ Options \{\lt{}file-options\gt{}\} ...]
+\index[dir]{Include \{ [ Options \{\lt{}file-options\gt{}\} ...]
\lt{}file-list\gt{} \} }
-\item [Options \ \{ \lt{}file-options\gt{} \} ]
-\index[dir]{Options \ \{ \lt{}file-options\gt{} \} }
+\item [Options \{ \lt{}file-options\gt{} \} ]
+\index[dir]{Options \{ \lt{}file-options\gt{} \} }
-\item [Exclude \ \{ \lt{}file-list\gt{} \}]
-\index[dir]{Exclude \ \{ \lt{}file-list\gt{} \} }
+\item [Exclude \{ \lt{}file-list\gt{} \}]
+\index[dir]{Exclude \{ \lt{}file-list\gt{} \} }
\end{description}
to use {\bf mtimeonly = yes} as well as keepatime (thanks to
Rudolf Cejka for this tip).
+\item [hardlinks=yes|no]
+\index[dir]{hardlinks}
+ When enabled (default), this directive will cause hardl inks to be
+ backed up. However, the File daemon keeps track of hard linked files and
+ will backup the data only once. The process of keeping track of the
+ hard links can be quite expensive if you have lots of them (tens of
+ thousands or more). This doesn't occur on normal Unix systems, but if
+ you use a program like BackupPC, it can create hundreds of thousands, or
+ even millions of hard links. Backups become very long and the File daemon
+ will consume a lot of CPU power checking hard links. In such a case,
+ set {\bf hardlinks=no} and hard links will not be backed up. Note, using
+ this option will most likely backup more data and on a restore the file
+ system will not be restored identically to the original.
+
\item [wild=\lt{}string\gt{}]
\index[dir]{wild }
Specifies a wild-card string to be applied to the filenames and
\index[general]{Considerations!Windows NTFS Naming }
\addcontentsline{toc}{paragraph}{Windows NTFS Naming Considerations}
-NTFS filenames containing Unicode characters (i.e. \gt{} 0xFF) cannot be
-explicitly named at the moment. You must include such names by naming a higher
-level directory or a drive letter that does not contain Unicode characters.
+NTFS filenames containing Unicode characters should now be supported
+as of version 1.37.30 or later.
\subsubsection*{Testing Your FileSet}
\index[general]{FileSet!Testing Your }
estimate} command in the Console program. See the
\ilink{estimate command}{estimate} in the Console chapter of this
manual.
-
-\subsubsection*{The Old FileSet Resource}
-\index[general]{Resource!Old FileSet }
-\index[general]{Old FileSet Resource }
-\addcontentsline{toc}{subsection}{Old FileSet Resource}
-
-The old pre-version 1.34.3 FileSet Resource has been deprecated but may still
-work. You are encouraged to convert to using the new form since the old code
-will be removed sometime during 1.37 development.
In general, you will need the Bacula source release, and if you want to run a
Windows client, you will need the Bacula Windows binary release. However,
-Bacula needs certain third party packages (such as {\bf SQLite}, {\bf MySQL}
+Bacula needs certain third party packages (such as {\bf SQLite}, {\bf MySQL}, or
+{\bf PostgreSQL}
to build properly depending on the options you specify. To simplify your task,
we have combined a number of these packages into two {\bf depkgs} releases
(Dependency Packages). This can vastly simplify your life by providing you
with valuable information about your SCSI tape drive (e.g. compression,
min/max block sizes, ...).
-The {\bf depkgs-win32} package contains the source code for the pthreads and
-zlib libraries used by the native Win32 client program. It will only be needed
+The {\bf depkgs-win32} package contains the source code for the pthreads,
+zlib, and wxWidgets libraries used by the native Win32 client program.
+It will only be needed
if you intend to build the Win32 client from source.
\subsection*{Supported Operating Systems}
\begin{description}
\item [ {-}{-}sysbindir=\lt{}binary-path\gt{}]
- \index[dir]{{-}{-}sysbindir }
+ \index[general]{{-}{-}sysbindir }
Defines where the Bacula binary (executable) files will be placed during a
{\bf make install} command.
\item [ {-}{-}sysconfdir=\lt{}config-path\gt{}]
- \index[dir]{{-}{-}sysconfdir }
+ \index[general]{{-}{-}sysconfdir }
Defines where the Bacula configuration files should be placed during a {\bf
make install} command.
\item [ {-}{-}enable-smartalloc ]
- \index[dir]{{-}{-}enable-smartalloc }
+ \index[general]{{-}{-}enable-smartalloc }
This enables the inclusion of the Smartalloc orphaned buffer detection code.
This option is highly recommended. Because we never build without this
option, you may experience problems if it is not enabled. In this case,
while building Bacula
\item [ {-}{-}enable-gnome ]
- \index[dir]{{-}{-}enable-gnome }
+ \index[general]{{-}{-}enable-gnome }
If you have GNOME installed on your computer and you want to use the GNOME
GUI Console interface to Bacula, you must specify this option. Doing so will
build everything in the {\bf src/gnome-console} directory.
\item [ {-}{-}enable-wx-console ]
- \index[console]{{-}{-}enable-wx-console }
+ \index[general]{{-}{-}enable-wx-console }
If you have wxWidgets installed on your computer and you want to use the
wxWidgets GUI Console interface to Bacula, you must specify this option.
Doing so will build everything in the {\bf src/wx-console} directory. This
\item [ {-}{-}enable-tray-monitor ]
- \index[dir]{{-}{-}enable-tray-monitor }
+ \index[general]{{-}{-}enable-tray-monitor }
If you have GTK installed on your computer, you run a graphical environment
or a window manager compatible with the FreeDesktop system tray standard
(like KDE and GNOME) and you want to use a GUI to monitor Bacula daemons, you
src/tray-monitor} directory.
\item [ {-}{-}enable-static-tools]
- \index[dir]{{-}{-}enable-static-tools }
+ \index[general]{{-}{-}enable-static-tools }
This option causes the linker to link the Storage daemon utility tools ({\bf
bls}, {\bf bextract}, and {\bf bscan}) statically. This permits using them
without having the shared libraries loaded. If you have problems linking in
\item [ {-}{-}enable-static-fd]
- \index[fd]{{-}{-}enable-static-fd }
+ \index[general]{{-}{-}enable-static-fd }
This option causes the make process to build a {\bf static-bacula-fd} in
addition to the standard File daemon. This static version will include
statically linked libraries and is required for the Bare Metal recovery. This
parts of the program are not compiled.
\item [ {-}{-}enable-static-sd]
- \index[sd]{{-}{-}enable-static-sd }
+ \index[general]{{-}{-}enable-static-sd }
This option causes the make process to build a {\bf static-bacula-sd} in
addition to the standard Storage daemon. This static version will include
statically linked libraries and could be useful during a Bare Metal recovery.
\item [ {-}{-}enable-static-dir]
- \index[dir]{{-}{-}enable-static-dir }
+ \index[general]{{-}{-}enable-static-dir }
This option causes the make process to build a {\bf static-bacula-dir} in
addition to the standard Director. This static version will include
statically linked libraries and could be useful during a Bare Metal recovery.
\item [ {-}{-}enable-static-cons]
- \index[dir]{{-}{-}enable-static-cons }
+ \index[general]{{-}{-}enable-static-cons }
This option causes the make process to build a {\bf static-console} and a
{\bf static-gnome-console} in addition to the standard console. This static
version will include statically linked libraries and could be useful during a
Bare Metal recovery.
\item [ {-}{-}enable-client-only]
- \index[console]{{-}{-}enable-client-only }
+ \index[general]{{-}{-}enable-client-only }
This option causes the make process to build only the File daemon and the
libraries that it needs. None of the other daemons, storage tools, nor the
console will be built. Likewise a {\bf make install} will then only install
Client on a client only machine.
\item [ {-}{-}enable-largefile]
- \index[console]{{-}{-}enable-largefile }
+ \index[general]{{-}{-}enable-largefile }
This option (default) causes Bacula to be built with 64 bit file address
support if it is available on your system. This permits Bacula to read and
write files greater than 2 GBytes in size. You may disable this feature and
revert to 32 bit file addresses by using {\bf \verb:--:disable-largefile}.
\item [ {-}{-}with-sqlite=\lt{}sqlite-path\gt{}]
- \index[fd]{{-}{-}with-sqlite }
- This enables use of the SQLite database. The {\bf sqlite-path} is not
+ \index[general]{{-}{-}with-sqlite }
+ This enables use of the SQLite version 2.8.x database. The {\bf sqlite-path} is not
normally specified as Bacula looks for the necessary components in a
standard location ({\bf depkgs/sqlite}). See
\ilink{Installing and Configuring SQLite}{_ChapterStart33} chapter of
this manual for more details.
+\item [ {-}{-}with-sqlite3=\lt{}sqlite3-path\gt{}]
+ \index[general]{{-}{-}with-sqlite3 }
+ This enables use of the SQLite version 3.x database. The {\bf sqlite3-path} is not
+ normally specified as Bacula looks for the necessary components in a
+ standard location ({\bf depkgs/sqlite3}). Although Bacula will run
+ with SQLite version 3.x, our testing shows that it is 4 to 10 times
+ slower than version 2.8.x and consequently, we do not recommend using
+ it. See
+ \ilink{Installing and Configuring SQLite}{_ChapterStart33} chapter of
+ this manual for more details.
+
\item [ {-}{-}with-mysql=\lt{}mysql-path\gt{}]
- \index[fd]{{-}{-}with-mysql }
+ \index[general]{{-}{-}with-mysql }
This enables building of the Catalog services for Bacula. It assumes that
MySQL is running on your system, and expects it to be installed in the {\bf
mysql-path} that you specify. If this option is not present, the build will
you use this option if possible. If you do use this option, please proceed to
installing MySQL in the
\ilink{Installing and Configuring MySQL}{_ChapterStart} chapter
- before proceeding with the configuration.
+ before proceeding with the configuration.
+
+\item [ {-}{-}with-openssl=\lt{}path\gt{}]
+ This configuration option is necessary if you want to enable TLS (ssl)
+ in Bacula. Normally, the {\bf path} specification is not necessary since
+ the configuration searches for the OpenSSL libraries in standard system
+ locations. Enabling OpenSSL in Bacula permits secure communications
+ between the daemons. For more information on using TLS, please see the
+ \ilink{Bacula TLS}{_ChapterStart61} chapter of this manual.
\item [ {-}{-}with-postgresql=\lt{}path\gt{}]
- \index[fd]{{-}{-}with-postgresql }
+ \index[general]{{-}{-}with-postgresql }
This provides an explicit path to the PostgreSQL libraries if Bacula cannot
find it by default.
\item [ {-}{-}with-python=\lt{}path\gt{}]
- \index[fd]{{-}{-}with-python }
+ \index[general]{{-}{-}with-python }
This option enables Bacula support for Python. If no path is
supplied, configure will search the
standard library locations for Python 2.2, 2.3, or 2.4. If it cannot
Python scripting.
\item [ {-}{-}enable-conio]
- \index[fd]{{-}{-}enable-conio }
+ \index[general]{{-}{-}enable-conio }
Tells Bacula to enable building the small, light weight readline replacement
routine. It is generally much easier to configure than readline, although,
like readline, it needs either the termcap or ncurses library.
\item [ {-}{-}with-readline=\lt{}readline-path\gt{}]
- \index[fd]{{-}{-}with-readline }
+ \index[general]{{-}{-}with-readline }
Tells Bacula where {\bf readline} is installed. Normally, Bacula will find
readline if it is in a standard library. If it is not found and no
\verb:--:with-readline is specified, readline will be disabled. This option affects
own if you have problems.
\item [ {-}{-}enable-readline]
- \index[fd]{{-}{-}enable-readline }
+ \index[general]{{-}{-}enable-readline }
Tells Bacula to enable readline support. It is normally disabled due to the
large number of configuration problems and the fact that the package seems to
change in incompatible ways from version to version.
\item [ {-}{-}with-tcp-wrappers=\lt{}path\gt{}]
- \index[fd]{{-}{-}with-tcp-wrappers }
+ \index[general]{{-}{-}with-tcp-wrappers }
This specifies that you want TCP wrappers (man hosts\_access(5)) compiled in.
The path is optional since Bacula will normally find the libraries in the
standard locations. This option affects the Bacula build. In specifying your
in the Security Chapter.
\item [ {-}{-}with-working-dir=\lt{}working-directory-path\gt{} ]
- \index[dir]{{-}{-}with-working-dir }
+ \index[general]{{-}{-}with-working-dir }
This option is mandatory and specifies a directory into which Bacula may
safely place files that will remain between Bacula executions. For example,
if the internal database is used, Bacula will keep those files in this
you must ensure that it exists before using Bacula for the first time.
\item [ {-}{-}with-base-port=\lt{}port=number\gt{}]
- \index[dir]{{-}{-}with-base-port }
+ \index[general]{{-}{-}with-base-port }
In order to run, Bacula needs three TCP/IP ports (one for the Bacula
Console, one for the Storage daemon, and one for the File daemon). The {\bf
\verb:--:with-baseport} option will automatically assign three ports beginning at
may also accomplish the same thing by directly editing them later.
\item [ {-}{-}with-dump-email=\lt{}email-address\gt{}]
- \index[dir]{{-}{-}with-dump-email }
+ \index[general]{{-}{-}with-dump-email }
This option specifies the email address where any core dumps should be set.
This option is normally only used by developers.
\item [ {-}{-}with-pid-dir=\lt{}PATH\gt{} ]
- \index[dir]{{-}{-}with-pid-dir }
+ \index[general]{{-}{-}with-pid-dir }
This specifies where Bacula should place the process id file during
execution. The default is: {\bf /var/run}. This directory is not created by
the install process, so you must ensure that it exists before using Bacula
the first time.
\item [ {-}{-}with-subsys-dir=\lt{}PATH\gt{}]
- \index[dir]{{-}{-}with-subsys-dir }
+ \index[general]{{-}{-}with-subsys-dir }
This specifies where Bacula should place the subsystem lock file during
execution. The default is {\bf /var/run/subsys}. Please make sure that you do
not specify the same directory for this directory and for the {\bf sbindir}
create it before using Bacula.
\item [ {-}{-}with-dir-password=\lt{}Password\gt{}]
- \index[dir]{{-}{-}with-dir-password }
+ \index[general]{{-}{-}with-dir-password }
This option allows you to specify the password used to access the Directory
(normally from the Console program). If it is not specified, configure will
automatically create a random password.
\item [ {-}{-}with-fd-password=\lt{}Password\gt{} ]
- \index[fd]{{-}{-}with-fd-password }
+ \index[general]{{-}{-}with-fd-password }
This option allows you to specify the password used to access the File daemon
(normally called from the Director). If it is not specified, configure will
automatically create a random password.
\item [ {-}{-}with-sd-password=\lt{}Password\gt{} ]
- \index[sd]{{-}{-}with-sd-password }
+ \index[general]{{-}{-}with-sd-password }
This option allows you to specify the password used to access the Directory
(normally called from the Director). If it is not specified, configure will
automatically create a random password.
\item [ {-}{-}with-dir-user=\lt{}User\gt{} ]
- \index[dir]{{-}{-}with-dir-user }
+ \index[general]{{-}{-}with-dir-user }
This option allows you to specify the Userid used to run the Director. The
Director must be started as root, but doesn't need to run as root, and after
doing preliminary initializations, it can ``drop'' to the UserId specified on
this option.
\item [ {-}{-}with-dir-group=\lt{}Group\gt{} ]
- \index[dir]{{-}{-}with-dir-group }
+ \index[general]{{-}{-}with-dir-group }
This option allows you to specify the GroupId used to run the Director. The
Director must be started as root, but doesn't need to run as root, and after
doing preliminary initializations, it can ``drop'' to the GroupId specified
on this option.
\item [ {-}{-}with-sd-user=\lt{}User\gt{} ]
- \index[sd]{{-}{-}with-sd-user }
+ \index[general]{{-}{-}with-sd-user }
This option allows you to specify the Userid used to run the Storage daemon.
The Storage daemon must be started as root, but doesn't need to run as root,
and after doing preliminary initializations, it can ``drop'' to the UserId
it needs.
\item [ {-}{-}with-sd-group=\lt{}Group\gt{} ]
- \index[sd]{{-}{-}with-sd-group }
+ \index[general]{{-}{-}with-sd-group }
This option allows you to specify the GroupId used to run the Storage daemon.
The Storage daemon must be started as root, but doesn't need to run as root,
and after doing preliminary initializations, it can ``drop'' to the GroupId
specified on this option.
\item [ {-}{-}with-fd-user=\lt{}User\gt{} ]
- \index[fd]{{-}{-}with-fd-user }
+ \index[general]{{-}{-}with-fd-user }
This option allows you to specify the Userid used to run the File daemon. The
File daemon must be started as root, and in most cases, it needs to run as
root, so this option is used only in very special cases, after doing
option.
\item [ {-}{-}with-fd-group=\lt{}Group\gt{} ]
- \index[fd]{{-}{-}with-fd-group }
+ \index[general]{{-}{-}with-fd-group }
This option allows you to specify the GroupId used to run the File daemon.
The File daemon must be started as root, and in most cases, it must be run as
root, however, after doing preliminary initializations, it can ``drop'' to
client programs and thus avoids the necessity of installing one or another of
those database programs to build the File daemon. With the above option, you
simply enter {\bf make} and just the client will be built.
-\label{autostart}
+\label{autostart}
\subsection*{Auto Starting the Daemons}
\index[general]{Daemons!Auto Starting the }
\index[general]{Auto Starting the Daemons }
\normalsize
Please note, that the auto-start feature is implemented only on systems that
-we officially support (currently, FreeBSD, RedHat Linux, and Solaris), and has
-only been fully tested on RedHat Linux.
+we officially support (currently, FreeBSD, RedHat/Fedora Linux, and Solaris), and has
+only been fully tested on Fedora Linux.
The {\bf make install-autostart} will cause the appropriate startup scripts to
-be installed with the necessary symbolic links. On RedHat Linux systems, these
+be installed with the necessary symbolic links. On RedHat/Fedora Linux systems, these
scripts reside in {\bf /etc/rc.d/init.d/bacula-dir} {\bf
/etc/rc.d/init.d/bacula-fd}, and {\bf /etc/rc.d/init.d/bacula-sd}. However the
exact location depends on what operating system you are using.
%%
%%
-\section*{Using Pools to Manage Volumes}
+\section*{Automated Disk Backup}
\label{_ChapterStart11}
\index[general]{Volumes!Using Pools to Manage }
+\index[general]{Disk!Automated Backup}
\index[general]{Using Pools to Manage Volumes }
+\index[general]{Automated Disk Backup}
\addcontentsline{toc}{section}{Using Pools to Manage Volumes}
+\addcontentsline{toc}{section}{Automated Disk Backup}
If you manage 5 or 10 machines and have a nice tape backup, you don't need
Pools, and you may wonder what they are good for. In this chapter, you will
The rest of this chapter will give an example involving backup to disk
Volumes, but most of the information applies equally well to tape Volumes.
-\label{TheProblem}
+\label{TheProblem}
\subsection*{The Problem}
\index[general]{Problem }
\addcontentsline{toc}{subsection}{Problem}
}
\end{verbatim}
\normalsize
-
\begin{itemize}
\item Item 1 will list the last 20 jobs run. If you find the Job you want,
- you can then select item 3 and enter its JobId(s).
+ you can then select item 3 and enter its JobId(s).
+
\item Item 2 will list all the Jobs where a specified file is saved. If you
- find the Job you want, you can then select item 3 and enter the JobId.
+ find the Job you want, you can then select item 3 and enter the JobId.
+
\item Item 3 allows you the enter a list of comma separated JobIds whose
files will be put into the directory tree. You may then select which
files from those JobIds to restore.
+
\item Item 4 allows you to enter any arbitrary SQL command. This is probably
the most primitive way of finding the desired JobIds, but at the same time,
the most flexible. Once you have found the JobId(s), you can select item 3
- and enter them.
+ and enter them.
+
\item Item 5 will automatically select the most recent Full backup and all
subsequent incremental and differential backups for a specified Client.
These are the Jobs and Files which, if reloaded, will restore your
automatically select the most recent Full backup and all subsequent
incremental and differential backups that started before the specified date
and time.
+
\item Item 7 allows you to specify one or more filenames (complete path
required) to be restored. Each filename is entered one at a time or if you
prefix a filename with the less-than symbol (\lt{}) Bacula will read that
file and assume it is a list of filenames to be restored. The filename entry
- mode is terminated by entering a blank line.
+ mode is terminated by entering a blank line.
+
\item Item 8 allows you to specify a date and time before entering the
- filenames. See Item 7 above for more details.
+ filenames. See Item 7 above for more details.
+
\item Item 9 allows you find the JobIds of the most recent backup for
a client. This is much like option 5 (it uses the same code), but
those JobIds are retained internally as if you had entered them
manually. You may then select item 11 (see below) to restore one
or more directories.
+
\item Item 10 is the same as item 9, except that it allows you to enter
a before date (as with item 6). These JobIds will then be retained
internally.
+
+\index[general]{Restore Directories}
\item Item 11 allows you to enter a list of JobIds from which you can
select directories to be restored. The list of JobIds can have been
previously created by using either item 9 or 10 on the menu. You
be restored, but if the directory contains subdirectories, nothing
will be restored in the subdirectory unless you explicitly enter its
name.
+
\item Item 12 allows you to cancel the restore command.
\end{itemize}
\index[general]{Restoring Files Can Be Slow }
\addcontentsline{toc}{subsection}{Restoring Files Can Be Slow}
-Restoring files is generally {\bf much} slower than backing it up for several
+Restoring files is generally {\bf much} slower than backing them up for several
reasons. The first is that during a backup the tape is normally already
positioned and Bacula only needs to write. On the other hand, because restoring
-files is done so rarely, Bacula keeps only the he start file and block on the
+files is done so rarely, Bacula keeps only the start file and block on the
tape for the whole job rather than on a file by file basis which would use
quite a lot of space in the catalog.
-Bacula versions 1.31a and older would seek to the first file on the first
-tape, then sequentially search the tape for the specified files. If you were
-doing a full restore, this is OK, but if you want to restore one or two files,
-the process could be quite long.
-
-This deficiency has been corrected in version 1.32. The consequence is that
Bacula will forward space to the correct file mark on the tape for the Job,
then forward space to the correct block, and finally sequentially read each
record until it gets to the correct one(s) for the file or files you want to
restore. Once the desired files are restored, Bacula will stop reading the
-tape. For restoring a small number of files, version 1.32 and greater are
-hundreds of times faster than previous versions.
+tape.
Finally, instead of just reading a file for backup, during the restore, Bacula
must create the file, and the operating system must allocate disk space for
restore. This is a new directive and untested.
\item Set ''Minimum Block Size = 512`` and ''Maximum Block Size = 512`` and
try the restore. Again send me the full job report output. If you are able
-to
+ to
determine the block size your drive was previously using, you should try
that size if 512 does not work.
\item Try editing the restore.bsr file at the Run xxx yes/mod/no prompt
before starting the restore job and remove all the VolBlock statements.
-These
+ These
are what causes Bacula to reposition the tape, and where problems occur if
you have a fixed block size set for your drive. The VolFile commands also
cause repositioning, but this will work regardless of the block size.
\item Use bextract to extract the files you want -- it reads the Volume
sequentially if you use the include list feature, or if you use a .bsr file,
but remove all the VolBlock statements after the .bsr file is created (at
-the
+ the
Run yes/mod/no) prompt but before you start the restore.
\end{enumerate}
\item [cd]
The {\bf cd} command changes the current directory to the argument
-specified.
+ specified.
It operates much like the Unix {\bf cd} command. Wildcard specifications are
not permitted.
Note, on Windows systems, the various drives (c:, d:, ...) are treated like
-a
+ a
directory within the file tree while in the file selection mode. As a
consequence, you must do a {\bf cd c:} or possibly in some cases a {\bf cd
C:} (note upper case) to get down to the first directory.
\index[dir]{dir }
The {\bf dir} command is similar to the {\bf ls} command, except that it
prints it in long format (all details). This command can be a bit slower
-than
+ than
the {\bf ls} command because it must access the catalog database for the
detailed information for each file.
\index[dir]{estimate }
The {\bf estimate} command prints a summary of the total files in the tree,
how many are marked to be restored, and an estimate of the number of bytes
-to
+ to
be restored. This can be useful if you are short on disk space on the
-machine
+ machine
where the files will be restored.
\item [find]
FileIndex=1-1
\end{verbatim}
\normalsize
- Where we have inserted the Volume name, Volume Session Id, and Volume Session Time that
- correspond to the values in the job report. We've also used a FileIndex of one,
+ Where we have inserted the Volume name, Volume Session Id, and Volume Session
+Time that
+ correspond to the values in the job report. We've also used a FileIndex of
+one,
which will always be the case providing that there was only one file
backed up in the job.
The disadvantage of this bootstrap file compared to what is created when you
ask for one to be written, is that there is no File and Block specified, so
the restore code must search all data in the Volume to find the requested
- file. A fully specified bootstrap file would have the File and Blocks specified
+ file. A fully specified bootstrap file would have the File and Blocks
+specified
as follows:
\footnotesize
\begin{verbatim}
\footnotesize
\begin{verbatim}
bls: butil.c:258 Using device: "/dev/nst0" for reading.
-21-Jul 18:34 bls: Ready to read from volume "DLT-22Apr05" on device "DLTDrive" (/dev/nst0).
+21-Jul 18:34 bls: Ready to read from volume "DLT-22Apr05" on device "DLTDrive"
+(/dev/nst0).
Volume Record: File:blk=0:0 SessId=11 SessTime=1114075126 JobId=0 DataLen=164
...
-Begin Job Session Record: File:blk=118:0 SessId=11 SessTime=1114075126 JobId=7510
+Begin Job Session Record: File:blk=118:0 SessId=11 SessTime=1114075126
+JobId=7510
Job=CatalogBackup.2005-04-22_01.10.0 Date=22-Apr-2005 10:21:00 Level=F Type=B
-End Job Session Record: File:blk=118:4053 SessId=11 SessTime=1114075126 JobId=7510
- Date=22-Apr-2005 10:23:06 Level=F Type=B Files=1 Bytes=210,739,395 Errors=0 Status=T
+End Job Session Record: File:blk=118:4053 SessId=11 SessTime=1114075126
+JobId=7510
+ Date=22-Apr-2005 10:23:06 Level=F Type=B Files=1 Bytes=210,739,395 Errors=0
+Status=T
...
-21-Jul 18:34 bls: End of Volume at file 201 on device "DLTDrive" (/dev/nst0), Volume "DLT-22Apr05"
+21-Jul 18:34 bls: End of Volume at file 201 on device "DLTDrive" (/dev/nst0),
+Volume "DLT-22Apr05"
21-Jul 18:34 bls: End of all volumes.
\end{verbatim}
\normalsize
Job Session Records, you can reconstruct a bootstrap file such as the one
shown above.
+\item[Problem]
+ How can I find where a file is stored.
+\item[Solution]
+ Normally, it is not necessary, you just use the {\bf restore} command to
+restore the
+ most recently saved version (menu option 5), or a version saved before a given
+date (menu
+ option 8). If you know the JobId of the job in which it was saved, you can
+use menu
+ option 3 to enter that JobId.
+
+ If you would like to know the JobId where a file was saved, select restore
+menu option
+ 2.
+
+ You can also use the {\bf query} command to find information such as:
+\footnotesize
+\begin{verbatim}
+*query
+Available queries:
+ 1: List Job totals:
+ 2: List up to 20 places where a File is saved regardless of the directory:
+ 3: List where the most recent copies of a file are saved:
+ 4: List last 20 Full Backups for a Client:
+ 5: List all backups for a Client after a specified time
+ 6: List all backups for a Client
+ 7: List Volume Attributes for a selected Volume:
+ 8: List Volumes used by selected JobId:
+ 9: List Volumes to Restore All Files:
+ 10: List Pool Attributes for a selected Pool:
+ 11: List total files/bytes by Job:
+ 12: List total files/bytes by Volume:
+ 13: List Files for a selected JobId:
+ 14: List Jobs stored in a selected MediaId:
+ 15: List Jobs stored for a given Volume name:
+Choose a query (1-15):
+\end{verbatim}
+\normalsize
+
\end{description}
depkgs/sqlite-2.8.16}. Please note that the version will be updated as new
versions are available and tested.
+You may install and use SQLite version 3.x with Bacula by using:
+{\bf ./configure \verb:--:with-sqlite3}. However, our testing indicates
+that SQLite version 3.x is 4 to 10 times slower than version 2.8.16, and
+consquently, we do not recommend using it.
+
Installing and Configuring is quite easy.
\begin{enumerate}
\index[general]{Testing SQLite }
\addcontentsline{toc}{subsection}{Testing SQLite}
-As of this date (20 March 2002), we have much less ``production'' experience
-using SQLite than using MySQL. That said, we should note that SQLite has
-performed flawlessly for us in all our testing.
+We have much less ``production'' experience
+using SQLite than using MySQL. SQLite has
+performed flawlessly for us in all our testing. However,
+several users have reported corrupted databases while using
+SQLite. For that reason, we do not recommend it for production
+use.
\subsection*{Re-initializing the Catalog Database}
\index[general]{Database!Re-initializing the Catalog }
\label{Autochanger}
\item [Autochanger = {\it Yes|No}]
- \index[sd]{Autochanger }
- If {\bf Yes}, this device is an automatic tape changer, and you should also
+ \index[sd]{Autochanger}
+ If {\bf Yes}, this device belongs to an automatic tape changer, and you should also
specify a {\bf Changer Device} as well as a {\bf Changer Command}. If {\bf
No} (default), the volume must be manually changed. You should also
have an identical directive to the
- \ilink{ Storage resource}{Autochanger1} in the Director's
+ \ilink{Storage resource}{Autochanger1} in the Director's
configuration file so that when labeling tapes you are prompted for the slot.
-
\item [Changer Device = {\it name-string}]
\index[sd]{Changer Device }
\normalsize
\item [Drive Index = {\it number}]
- \index[sd]{Drive Index }
+ \index[sd]{Drive Index}
The {\bf Drive Index} that you specify is passed to the {\bf mtx-changer}
script and is thus passed to the {\bf mtx} program. By default, the Drive
Index is zero, so if you have only one drive in your autochanger, everything
Volume on both drives at the same time. You may also need to modify the
mtx-changer script to do locking so that two jobs don't attempt to use the
autochanger at the same time. An example script can be found in {\bf
- examples/autochangers/locking-mtx-changer}.
+ examples/autochangers/locking-mtx-changer}.
+
+\item [Autoselect = {\it Yes|No}]
+ \index[sd]{Autoselect}
+ If this directive is set to {\bf yes} (default), and the Device
+ belongs to an autochanger, then when the Autochanger is referenced
+ by the Director, this device can automatically be selected. If this
+ directive is set to {\bf no}, then the Device can only be referenced
+ by directly using the Device name in the Director. This is useful
+ for reserving a drive for something special such as a high priority
+ backup or restore operations.
\item [Maximum Changer Wait = {\it time}]
\index[sd]{Maximum Changer Wait }
maintained.
\item The wxWidgets Console program is developed and tested with the latest
stable ANSI (not Unicode) version of
-\elink{wxWidgets}{http://www.wxwidgets.org/} (2.6.0). It works fine with the
-Windows and GTK+-2.x version of wxWidgets, and should also works on other
-platforms supported by wxWidgets.
+\elink{wxWidgets}{http://www.wxwidgets.org/} (2.6.0) for Unix and Linux
+systems. On Win32, we use wxWidgets version 2.4.0 compiled with Unicode
+enable. It should also work on other platforms supported by wxWidgets.
\item The Tray Monitor program is developed for GTK+-2.x. It needs Gnome less
or equal to 2.2, KDE greater or equal to 3.1 or any window manager supporting
the
ftp -i ftp.sectoor.de <<END_OF_DATA
cd www/htdocs/dev-manual
-lcd /home/kern/bacula/k/doc/latex/bacula
+lcd /home/kern/bacula/docs/manual/bacula
mput *
-cd ../html-manual
-put faq.html
-put Conf-Diagram.png
cd ..
lcd ..
-put bacula.pdf dev-bacula.pdf
+put dev-bacula.pdf dev-bacula.pdf
quit
END_OF_DATA
\label{VSS}
\subsection*{Volume Shadow Copy Service}
-\index[general]{Volume Shadow Copy Service }
+\index[general]{Volume Shadow Copy Service}
+\index[general]{VSS}
\addcontentsline{toc}{subsection}{Volume Shadow Copy Service}
-In version 1.37.25 and greater, you can turn on Microsoft's Volume
+In version 1.37.30 and greater, you can turn on Microsoft's Volume
Shadow Copy Service (VSS).
Microsoft added VSS to Windows XP and Windows 2003. From the perspective of
a backup-solution for Windows, this is an extremely important step. VSS
allows Bacula to backup open files and even to interact with applications like
-RDBMS to produce consistent file copies.
+RDBMS to produce consistent file copies. VSS aware applications are called
+VSS Writers, they register with the OS so that when Bacula wants to do a
+Snapshot, the OS will notify the register Writer programs, which may then
+create a consistent state in their application, which will be backed up.
+Examples for these writers are "MSDE" (Microsoft database
+engine), "Event Log Writer", "Registry Writer" plus 3rd
+party-writers. If you have a non-vss aware application (e.g.
+SQL Anywhere or probably MySQL), a shadow copy is still generated
+and the open files can be backed up, but there is no guarantee
+that the file is consistent.
+
+Bacula produces a message from each of the registered writer programs
+when it is doing a VSS backup so you know which ones are correctly backed
+up.
Bacula supports VSS on both Windows 2003 and Windows XP.
Technically Bacula creates a shadow copy as soon as the backup process
VSS can be turned on by placing an
+\index[dir]{Enable VSS}
+\index[general]{Enable VSS}
\begin{verbatim}
Enable VSS = yes
\end{verbatim}
in your FileSet resource.
+Important Note!! Under the current implementation, you may only
+run a single job at a time in any Win32 File daemon that has VSS
+active. Running multiple simultanous jobs in the File daemon
+will most likely cause jobs to fail. This restriction does not apply
+to the Director, Storage daemons, or any File daemons not running
+VSS.
+
+The VSS aware File daemon has the letters VSS on the signon line that
+it produces when contacted by the console. For example:
+\begin{verbatim}
+Tibs-fd Version: 1.37.32 (22 July 2005) VSS Windows XP MVS NT 5.1.2600
+\end{verbatim}
+the VSS is shown in the line above. This only means that the File daemon
+is capable of doing VSS not that VSS is turned on for a particular backup.
+There are two ways of telling if VSS is actually turned on during a backup.
+The first is to look at the status output for a job, e.g.:
+\footnotesize
+\begin{verbatim}
+Running Jobs:
+JobId 1 Job NightlySave.2005-07-23_13.25.45 is running.
+ VSS Backup Job started: 23-Jul-05 13:25
+ Files=70,113 Bytes=3,987,180,650 Bytes/sec=3,244,247
+ Files Examined=75,021
+ Processing file: c:/Documents and Settings/kern/My Documents/My Pictures/Misc1/Sans titre - 39.pdd
+ SDReadSeqNo=5 fd=352
+\end{verbatim}
+\normalsize
+Here, you see under Running Jobs that JobId 1 is ``VSS Backup Job started ...''
+This means that VSS is enabled for that job. If VSS is not enabled, it will
+simply show ``Backup Job started ...'' without the letters VSS.
+
+The second way to know that the job was backed up with VSS is to look at the
+Job Report, which will look something like the following:
+\footnotesize
+\begin{verbatim}
+23-Jul 13:25 rufus-dir: Start Backup JobId 1, Job=NightlySave.2005-07-23_13.25.45
+23-Jul 13:26 rufus-sd: Wrote label to prelabeled Volume "TestVolume001" on device "DDS-4" (/dev/nst0)
+23-Jul 13:26 rufus-sd: Spooling data ...
+23-Jul 13:26 Tibs: Generate VSS snapshots. Driver="VSS WinXP", Drive(s)="C"
+23-Jul 13:26 Tibs: VSS Writer: "MSDEWriter", State: 1 (VSS_WS_STABLE)
+23-Jul 13:26 Tibs: VSS Writer: "Microsoft Writer (Bootable State)", State: 1 (VSS_WS_STABLE)
+23-Jul 13:26 Tibs: VSS Writer: "WMI Writer", State: 1 (VSS_WS_STABLE)
+23-Jul 13:26 Tibs: VSS Writer: "Microsoft Writer (Service State)", State: 1 (VSS_WS_STABLE)
+\end{verbatim}
+\normalsize
+In the above Job Report listing, you see that the VSS snapshot was generated for drive C (if
+other drives are backed up, they will be listed on the {\bf Drive(s)="C"} You also see the
+reports from each of the writer program. Here they all report VSS_WS_STABLE, which means
+that you will get a consistent snapshot of the data handled by that writer.
\subsection*{Windows Firewalls}
\index[general]{Firewalls!Windows }
for important considerations on how to specify Windows paths in Bacula FileSet
Include and Exclude directives.
+\index[general]{Unicode}
Bacula versions prior to 1.37.28 do not support Windows Unicode filenames.
As of that version, both {\bf bconsole} and {\bf wx-console} support Windows
Unicode filenames. There may still be some problems with multiple byte
characters (e.g. Chinese, ...) where it is a two byte character but the
displayed character is not two characters wide.
+\index[general]{Win32 path length restriction}
Path/filenames longer than 260 characters are not supported. This may be
possible in a future version.
Client Run After Job directive. If you want to do something similar, you might
take the shutdown program from the
\elink{apcupsd project}{http://www.apcupsd.com} or one from the
-\elink{ Sysinternals
-project}{http://www.sysinternals.com/ntw2k/freeware/psshutdown.shtml}.
+\elink{Sysinternals project}{http://www.sysinternals.com/ntw2k/freeware/psshutdown.shtml}.
projects / bacula / docs / commitdiff