4 \chapter{Getting Started with Bacula}
5 \label{QuickStartChapter}
6 \index[general]{Getting Started with Bacula }
8 If you are like me, you want to get Bacula running immediately to get a feel
9 for it, then later you want to go back and read about all the details. This
10 chapter attempts to accomplish just that: get you going quickly without all
11 the details. If you want to skip the section on Pools, Volumes and Labels, you
12 can always come back to it, but please read to the end of this chapter, and in
13 particular follow the instructions for testing your tape drive.
15 We assume that you have managed to build and install Bacula, if not, you might
16 want to first look at the
17 \ilink{System Requirements}{SysReqs} then at the
18 \ilink{Compiling and Installing Bacula}{InstallChapter} chapter of
21 \label{JobsandSchedules}
22 \section{Understanding Jobs and Schedules}
23 \index[general]{Jobs!Understanding}
24 \index[general]{Schedules!Understanding}
26 In order to make Bacula as flexible as possible, the directions given
27 to Bacula are specified in several pieces. The main instruction is the
28 job resource, which defines a job. A backup job generally consists of a
29 FileSet, a Client, a Schedule for one or several levels or times of backups,
30 a Pool, as well as additional instructions. Another way of looking
31 at it is the FileSet is what to backup; the Client is who to backup; the
32 Schedule defines when, and the Pool defines where (i.e. what Volume).
34 Typically one FileSet/Client combination will have one corresponding job.
35 Most of the directives, such as FileSets, Pools, Schedules, can be mixed
36 and matched among the jobs. So you might have two different Job
37 definitions (resources) backing up different servers using the same
38 Schedule, the same Fileset (backing up the same directories on two machines)
39 and maybe even the same Pools. The Schedule will define what type of
40 backup will run when (e.g. Full on Monday, incremental the rest of the
41 week), and when more than one job uses the same schedule, the job priority
42 determines which actually runs first. If you have a lot of jobs, you might
43 want to use JobDefs, where you can set defaults for the jobs, which can
44 then be changed in the job resource, but this saves rewriting the
45 identical parameters for each job. In addition to the FileSets you want to
46 back up, you should also have a job that backs up your catalog.
48 Finally, be aware that in addition to the backup jobs there are
49 restore, verify, and admin jobs, which have different requirements.
51 \label{PoolsVolsLabels}
52 \section{Understanding Pools, Volumes and Labels}
53 \index[general]{Labels!Understanding Pools Volumes and }
54 \index[general]{Understanding Pools, Volumes and Labels }
56 If you have been using a program such as {\bf tar} to backup your system,
57 Pools, Volumes, and labeling may be a bit confusing at first. A Volume is a
58 single physical tape (or possibly a single file) on which Bacula will write
59 your backup data. Pools group together Volumes so that a backup is not
60 restricted to the length of a single Volume (tape). Consequently, rather than
61 explicitly naming Volumes in your Job, you specify a Pool, and Bacula will
62 select the next appendable Volume from the Pool and request you to mount it.
63 % TODO: can't it mount it itself if already available?
65 Although the basic Pool options are specified in the Director's Pool resource,
66 the {\bf real} Pool is maintained in the Bacula Catalog. It contains
67 information taken from the Pool resource (bacula-dir.conf) as well as
68 information on all the Volumes that have been added to the Pool. Adding
69 Volumes to a Pool is usually done manually with the Console program using the
72 For each Volume, Bacula maintains a fair amount of catalog information such as
73 the first write date/time, the last write date/time, the number of files on
74 the Volume, the number of bytes on the Volume, the number of Mounts, etc.
76 Before Bacula will read or write a Volume, the physical Volume must have a
77 Bacula software label so that Bacula can be sure the correct Volume is
78 mounted. This is usually done using the {\bf label} command in the Console
81 The steps for creating a Pool, adding Volumes to it, and writing software
82 labels to the Volumes, may seem tedious at first, but in fact, they are quite
83 simple to do, and they allow you to use multiple Volumes (rather than being
84 limited to the size of a single tape). Pools also give you significant
85 flexibility in your backup process. For example, you can have a "Daily" Pool
86 of Volumes for Incremental backups and a "Weekly" Pool of Volumes for Full
87 backups. By specifying the appropriate Pool in the daily and weekly backup
88 Jobs, you thereby insure that no daily Job ever writes to a Volume in the
89 Weekly Pool and vice versa, and Bacula will tell you what tape is needed and
92 For more on Pools, see the
93 \ilink{Pool Resource}{PoolResource} section of the Director
94 Configuration chapter, or simply read on, and we will come back to this
97 \section{Setting Up Bacula Configuration Files}
99 \index[general]{Setting Up Bacula Configuration Files }
100 \index[general]{Files!Setting Up Bacula Configuration }
102 % TODO: this assumes installation from source:
103 After running the appropriate {\bf ./configure} command and doing
104 a {\bf make}, and a {\bf make install}, if this is the first time
105 you are running Bacula, you must create valid configuration files
106 for the Director, the File daemon, the Storage daemon, and the
107 Console programs. If you have followed our recommendations,
108 default configuration files as well as the daemon binaries will
109 be located in your installation directory. In any case, the
110 binaries are found in the directory you specified on the {\bf
111 \verb:--:sbindir} option to the {\bf ./configure} command, and
112 the configuration files are found in the directory you specified
113 on the {\bf \verb:--:sysconfdir} option.
115 When initially setting up Bacula you will need to invest a bit of time in
116 modifying the default configuration files to suit your environment. This may
117 entail starting and stopping Bacula a number of times until you get everything
118 right. Please do not despair. Once you have created your configuration files,
119 you will rarely need to change them nor will you stop and start Bacula very
120 often. Most of the work will simply be in changing the tape when it is full.
122 \subsection{Configuring the Console Program}
123 \index[general]{Configuring the Console Program }
124 \index[general]{Program!Configuring the Console }
126 The Console program is used by the administrator to interact with the Director
127 and to manually start/stop Jobs or to obtain Job status information.
129 The Console configuration file is found in the directory specified on the
130 {\bf \verb:--:sysconfdir} option that you specified on the {\bf
131 ./configure} command and by default is named {\bf bconsole.conf}.
133 If you choose to build the GNOME console with the {\bf
134 \verb:--:enable-gnome} option, you also find a default configuration file
135 for it, named {\bf bgnome-console.conf}.
137 The same applies to the wxWidgets console, which is build with the {\bf
138 \verb:--:enable-bwx-console} option, and the name of the default
139 configuration file is, in this case, {\bf bwx-console.conf}.
141 Normally, for first time users, no change is needed to these files. Reasonable
144 Further details are in the
145 \ilink{Console configuration}{ConsoleConfChapter} chapter.
147 \subsection{Configuring the Monitor Program}
148 \index[general]{Program!Configuring the Monitor }
149 \index[general]{Configuring the Monitor Program }
151 The Monitor program is typically an icon in the system tray. However, once the
152 icon is expanded into a full window, the administrator or user can obtain
153 status information about the Director or the backup status on the local
154 workstation or any other Bacula daemon that is configured.
156 \addcontentsline{lof}{figure}{Bacula Tray Monitor}
157 \includegraphics{./Bacula-tray-monitor.eps}
159 % TODO: image may be too wide for 6" wide printed page.
160 The image shows a tray-monitor configured for three daemons. By clicking on
161 the radio buttons in the upper left corner of the image, you can see the
162 status for each of the daemons. The image shows the status for the Storage
163 daemon (MainSD) that is currently selected.
165 The Monitor configuration file is found in the directory specified on the {\bf
166 \verb:--:sysconfdir} option that you specified on the {\bf ./configure} command
168 by default is named {\bf tray-monitor.conf}. Normally, for first time users,
169 you just need to change the permission of this file to allow non-root users to
170 run the Monitor, as this application must run as the same user as the
171 graphical environment (don't forget to allow non-root users to execute {\bf
172 bacula-tray-monitor}). This is not a security problem as long as you use the
175 More information is in the
176 \ilink{Monitor configuration}{_MonitorChapter} chapter.
178 \subsection{Configuring the File daemon}
179 \index[general]{Daemon!Configuring the File }
180 \index[general]{Configuring the File daemon }
182 The File daemon is a program that runs on each (Client) machine. At the
183 request of the Director, finds the files to be backed up and sends them (their
184 data) to the Storage daemon.
186 The File daemon configuration file is found in the directory specified on
187 the {\bf \verb:--:sysconfdir} option that you specified on the {\bf ./configure}
188 command. By default, the File daemon's configuration file is named {\bf
189 bacula-fd.conf}. Normally, for first time users, no change is needed to this
190 file. Reasonable defaults are set. However, if you are going to back up more
191 than one machine, you will need to install the File daemon with a unique
192 configuration file on each machine to be backed up. The information about each
193 File daemon must appear in the Director's configuration file.
194 % TODO: point to section about how to install just the File daemon
195 % TODO: and creating the unique configuration file.
197 Further details are in the
198 \ilink{File daemon configuration}{FiledConfChapter} chapter.
200 \subsection{Configuring the Director}
201 \index[general]{Director!Configuring the }
202 \index[general]{Configuring the Director }
204 The Director is the central control program for all the other daemons. It
205 schedules and monitors all jobs to be backed up.
207 The Director configuration file is found in the directory specified on the
208 {\bf \verb:--:sysconfdir} option that you specified on the {\bf ./configure}
209 command. Normally the Director's configuration file is named {\bf bacula-dir.conf}.
211 In general, the only change you must make is modify the FileSet resource so
212 that the {\bf Include} configuration directive contains at least one line with
213 a valid name of a directory (or file) to be saved.
215 % TODO: is DLT still the default config?
216 If you do not have a DLT tape drive, you will probably want to edit the
217 Storage resource to contain names that are more representative of your actual
218 storage device. You can always use the existing names as you are free to
219 arbitrarily assign them, but they must agree with the corresponding names in
220 the Storage daemon's configuration file.
222 You may also want to change the email address for notification from the
223 default {\bf root} to your email address.
225 Finally, if you have multiple systems to be backed up, you will need a
226 separate File daemon or Client specification for each system, specifying its
227 % TODO: I don't see any example "File" configuraton in the default
228 % TODO: bacula-dir.conf; I do see FileDaemon config in the default
229 % TODO: bacula-fd.conf. Be more clear about this or point to explanation
231 name, address, and password. We have found that giving your daemons the same
232 % TODO: what passwords should I use? I have different ones in the
233 % TODO: different configs on different systems. Point to explanation of
235 name as your system but post fixed with {\bf -fd} helps a lot in debugging.
236 That is, if your system name is {\bf foobaz}, you would give the File daemon
237 the name {\bf foobaz-fd}. For the Director, you should use {\bf foobaz-dir},
238 and for the storage daemon, you might use {\bf foobaz-sd}.
239 Each of your Bacula components {\bf must} have a unique name. If you
240 make them all the same, aside from the fact that you will not
241 know what daemon is sending what message, if they share the same
242 working directory, the daemons temporary file names will not
243 be unique, and you will get many strange failures.
244 % TODO: why not check for that and not allow sharing working directory?
246 More information is in the
247 \ilink{Director configuration}{DirectorChapter} chapter.
249 \subsection{Configuring the Storage daemon}
250 \index[general]{Daemon!Configuring the Storage }
251 \index[general]{Configuring the Storage daemon }
253 The Storage daemon is responsible, at the Director's request, for accepting
254 data from a File daemon and placing it on Storage media, or in the case of a
255 restore request, to find the data and send it to the File daemon.
257 The Storage daemon's configuration file is found in the directory specified on
258 the {\bf \verb:--:sysconfdir} option that you specified on the {\bf ./configure}
259 command. By default, the Storage daemon's file is named {\bf bacula-sd.conf}.
260 Edit this file to contain the correct Archive device names for any tape
261 devices that you have. If the configuration process properly detected your
262 system, they will already be correctly set. These Storage resource name and
263 Media Type must be the same as the corresponding ones in the Director's
264 configuration file {\bf bacula-dir.conf}. If you want to backup to a file
265 instead of a tape, the Archive device must point to a directory in which the
266 Volumes will be created as files when you label the Volume.
267 \label{ConfigTesting}
269 Further information is in the
270 \ilink{Storage daemon configuration}{StoredConfChapter} chapter.
272 \section{Testing your Configuration Files}
273 \index[general]{Testing your Configuration Files }
274 \index[general]{Files!Testing your Configuration }
276 You can test if your configuration file is syntactically correct by running
277 the appropriate daemon with the {\bf -t} option. The daemon will process the
278 configuration file and print any error messages then terminate. For example,
279 assuming you have installed your binaries and configuration files in the same
281 % TODO: why assume that? common default install has the executable
282 % TODO: is in ./sbin and the configs are in ./etc. So maybe just have
283 % TODO: example correct or change default install to be same.
287 cd <installation-directory>
288 ./bacula-dir -t -c bacula-dir.conf
289 ./bacula-fd -t -c bacula-fd.conf
290 ./bacula-sd -t -c bacula-sd.conf
291 ./bconsole -t -c bconsole.conf
292 ./bgnome-console -t -c bgnome-console.conf
293 ./bwx-console -t -c bwx-console.conf
295 su <normal user> -c "./bacula-tray-monitor -t -c tray-monitor.conf"
299 will test the configuration files of each of the main programs. If the
300 configuration file is OK, the program will terminate without printing
301 anything. Please note that, depending on the configure options you choose,
302 some, or even all, of the three last commands will not be available on your
303 system. If you have installed the binaries in traditional Unix locations
304 rather than a single file, you will need to modify the above commands
305 appropriately (no ./ in front of the command name, and a path in front of the
309 \section{Testing Compatibility with Your Tape Drive}
310 \index[general]{Drive!Testing Bacula Compatibility with Your Tape}
311 \index[general]{Testing Bacula Compatibility with Your Tape Drive}
313 Before spending a lot of time on Bacula only to find that it doesn't work
314 with your tape drive, please read the \ilink{btape -- Testing Your Tape
315 Drive}{TapeTestingChapter} chapter of this manual. If you have a modern
316 standard SCSI tape drive on a Linux or Solaris, most likely it will work,
317 but better test than be sorry. For FreeBSD (and probably other xBSD
318 flavors), reading the above mentioned tape testing chapter is a must.
319 Also, for FreeBSD, please see \elink{The FreeBSD
320 Diary}{\url{http://www.freebsddiary.org/bacula.php}} for a detailed description
321 %TODO: fix elink so it shows URL in PDF
322 on how to make Bacula work on your system. In addition, users of FreeBSD
323 prior to 4.9-STABLE dated Mon Dec 29 15:18:01 2003 UTC who plan to use tape
324 devices, please see the file {\bf platforms/freebsd/pthreads-fix.txt} in
325 the main Bacula directory concerning important information concerning
326 compatibility of Bacula and your system. \label{notls}
328 \section{Get Rid of the /lib/tls Directory}
329 \index[general]{Directory!Get Rid of the /lib/tls }
330 \index[general]{Get Rid of the /lib/tls Directory }
332 % TODO: this seems dangerous -- how do you know if they don't use
333 % TODO: /lib/tls for something mission critical? Reword this or point to
334 % TODO: appropriate documentation.
336 The new pthreads library {\bf /lib/tls} installed by default on recent Red Hat
337 systems running Linux kernel 2.4.x is defective. You must remove it or rename it,
338 then reboot your system before running Bacula otherwise after a week or so of
339 running, Bacula will either block for long periods or deadlock entirely.
340 You may want to use the loader environment variable override rather
341 than removing /lib/tls. Please see \ilink{ Supported Operating
342 Systems}{SupportedOSes} for more
343 information on this problem.
345 This problem does not occur on systems running Linux 2.6.x kernels.
349 \section{Running Bacula}
350 \index[general]{Bacula!Running }
351 \index[general]{Running Bacula }
353 Probably the most important part of running Bacula is being able to restore
354 files. If you haven't tried recovering files at least once, when you actually
355 have to do it, you will be under a lot more pressure, and prone to make
356 errors, than if you had already tried it once.
358 To get a good idea how to use Bacula in a short time, we {\bf strongly}
359 recommend that you follow the example in the
360 \ilink{Running Bacula Chapter}{TutorialChapter} of this manual where
361 you will get detailed instructions on how to run Bacula.
363 \section{Log Rotation}
364 \index[general]{Rotation!Log }
365 \index[general]{Log Rotation }
366 If you use the default {\bf bacula-dir.conf} or some variation of it, you will
367 note that it logs all the Bacula output to a file. To avoid that this file
368 grows without limit, we recommend that you copy the file {\bf logrotate} from
369 the {\bf scripts/logrotate} to {\bf /etc/logrotate.d/bacula}. This will cause
370 the log file to be rotated once a month and kept for a maximum of five months.
371 You may want to edit this file to change the default log rotation preferences.
374 \index[general]{Watch!Log}
375 \index[general]{Log Watch}
376 Some systems such as Red Hat and Fedora run the logwatch program
377 every night, which does an analysis of your log file and sends an
378 email report. If you wish to include the output from your Bacula
379 jobs in that report, please look in the {\bf scripts/logwatch}
380 directory. The {\bf README} file in that directory gives a brief
381 explanation on how to install it and what kind of output to expect.
384 \section{Disaster Recovery}
385 \index[general]{Recovery!Disaster }
386 \index[general]{Disaster Recovery }
388 If you intend to use Bacula as a disaster recovery tool rather than simply a
389 program to restore lost or damaged files, you will want to read the
390 \ilink{Disaster Recovery Using Bacula Chapter}{RescueChapter} of
393 In any case, you are strongly urged to carefully test restoring some files
394 that you have saved rather than wait until disaster strikes. This way, you