4
\section*{Tips and Suggestions}
6
\index[general]{Tips and Suggestions }
7
\index[general]{Suggestions!Tips and }
8
\addcontentsline{toc}{section}{Tips and Suggestions}
10
\subsection*{Examples}
12
\index[general]{Examples }
13
\addcontentsline{toc}{subsection}{Examples}
15
There are a number of example scripts for various things that can be found in
16
the {\bf example} subdirectory and its subdirectories of the Bacula source
19
\subsection*{Upgrading Bacula Versions}
21
\index[general]{Upgrading Bacula Versions }
22
\index[general]{Versions!Upgrading Bacula }
23
\addcontentsline{toc}{subsection}{Upgrading Bacula Versions}
25
The first thing to do before upgrading from one version to another is to
26
ensure that you don't overwrite or delete your production (current) version of Bacula until
27
you have tested that the new version works.
29
If you have installed Bacula into a single directory, this is simple: simply
30
make a copy of your Bacula directory.
32
If you have done a more typical Unix installation where the binaries are
33
placed in one directory and the configuration files are placed in another,
34
then the simplest way is to configure your new Bacula to go into a single
35
file. Alternatively, make copies of all your binaries and especially your
38
Whatever your situation may be (one of the two just described), you should
39
probably start with the {\bf defaultconf} script that can be found in the {\bf
40
examples} subdirectory. Copy this script to the main Bacula directory, modify
41
it as necessary (there should not need to be many modifications), configure
42
Bacula, build it, install it, then stop your production Bacula, copy all the
43
{\bf *.conf} files from your production Bacula directory to the test Bacula
44
directory, start the test version, and run a few test backups. If all seems
45
good, then you can proceed to install the new Bacula in place of or possibly
48
When installing a new Bacula you need not worry about losing the changes you
49
made to your configuration files as the installation process will not
50
overwrite them providing that you do not do a {\bf make uninstall}.
52
If the new version of Bacula requires an upgrade to the database,
53
you can upgrade it with the script {\bf update_bacula_tables}, which
54
will be installed in your scripts directory (default {\bf /etc/bacula}),
55
or alternatively, you can find it in the
56
{\bf \lt{}bacula-source\gt{}/src/cats} directory.
58
\subsection*{Getting Notified of Job Completion}
60
\index[general]{Getting Notified of Job Completion }
61
\index[general]{Completion!Getting Notified of Job }
62
\addcontentsline{toc}{subsection}{Getting Notified of Job Completion}
64
One of the first things you should do is to ensure that you are being properly
65
notified of the status of each Job run by Bacula, or at a minimum of each Job
66
that terminates with an error.
68
Until you are completely comfortable with {\bf Bacula}, we recommend that you
69
send an email to yourself for each Job that is run. This is most easily
70
accomplished by adding an email notification address in the {\bf Messages}
71
resource of your Director's configuration file. An email is automatically
72
configured in the default configuration files, but you must ensure that the
73
default {\bf root} address is replaced by your email address.
75
For examples of how I (Kern) configure my system, please take a look at the
76
{\bf .conf} files found in the {\bf examples} sub-directory. We recommend the
77
following configuration (where you change the paths and email address to
78
correspond to your setup). Note, the {\bf mailcommand} and {\bf
79
operatorcommand} should be on a single line. They were split here for
86
mailcommand = "/home/bacula/bin/bsmtp -h localhost
88
-s \"Bacula: %t %e of %c %l\" %r"
89
operatorcommand = "/home/bacula/bin/bsmtp -h localhost
91
-s \"Bacula: Intervention needed for %j\" %r"
92
Mail = your-email-address = all, !skipped, !terminate
93
append = "/home/bacula/bin/log" = all, !skipped, !terminate
94
operator = your-email-address = mount
95
console = all, !skipped, !saved
100
You will need to ensure that the {\bf /home/bacula/bin} path on the {\bf
101
mailcommand} and the {\bf operatorcommand} lines point to your {\bf Bacula}
102
binary directory where the {\bf bsmtp} program will be installed. You will
103
also want to ensure that the {\bf your-email-address} is replaced by your
104
email address, and finally, you will also need to ensure that the {\bf
105
/home/bacula/bin/log} points to the file where you want to log all messages.
107
With the above Messages resource, you will be notified by email of every Job
108
that ran, all the output will be appended to the {\bf log} file you specify,
109
all output will be directed to the console program, and all mount messages
110
will be emailed to you. Note, some messages will be sent to multiple
113
The form of the mailcommand is a bit complicated, but it allows you to
114
distinguish whether the Job terminated in error or terminated normally. Please
116
\ilink{Mail Command}{mailcommand} section of the Messages
117
Resource chapter of this manual for the details of the substitution characters
120
Once you are totally comfortable with Bacula as I am, or if you have a large
121
number of nightly Jobs as I do (eight), you will probably want to change the
122
{\bf Mail} command to {\bf Mail On Error} which will generate an email message
123
only if the Job terminates in error. If the Job terminates normally, no email
124
message will be sent, but the output will still be appended to the log file as
125
well as sent to the Console program.
127
\subsection*{Getting Email Notification to Work}
129
\index[general]{Work!Getting Email Notification to }
130
\index[general]{Getting Email Notification to Work }
131
\addcontentsline{toc}{subsection}{Getting Email Notification to Work}
133
The section above describes how to get email notification of job status.
134
Occasionally, however, users have problems receiving any email at all. In that
135
case, the things to check are the following:
138
\item Ensure that you have a valid email address specified on your {\bf Mail}
139
record in the Director's Messages resource. The email address should be fully
140
qualified. Simply using {\bf root} generally will not work, rather you should
141
use {\bf root@localhost} or better yet your full domain.
142
\item Ensure that you do not have a {\bf Mail} record in the Storage daemon's
143
or File daemon's configuration files. The only record you should have is {\bf
148
director = director-name = all
153
\item If all else fails, try replacing the {\bf mailcommand} with
157
mailcommand = "mail -s test your@domain.com"
161
\item Once the above is working, assuming you want to use {\bf bsmtp}, submit
162
the desired bsmtp command by hand and ensure that the email is delivered,
163
then put that command into {\bf Bacula}. Small differences in things such as
164
the parenthesis around the word Bacula can make a big difference to some
165
bsmtp programs. For example, you might start simply by using:
169
mailcommand = "/home/bacula/bin/bsmtp -f \"root@localhost\" %r"
175
\subsection*{Getting Notified that Bacula is Running}
176
\label{JobNotification}
177
\index[general]{Running!Getting Notified that Bacula is }
178
\index[general]{Getting Notified that Bacula is Running }
179
\addcontentsline{toc}{subsection}{Getting Notified that Bacula is Running}
181
If like me, you have setup Bacula so that email is sent only when a Job has
182
errors, as described in the previous section of this chapter, inevitably, one
183
day, something will go wrong and {\bf Bacula} can stall. This could be because
184
Bacula crashes, which is vary rare, or more likely the network has caused {\bf
185
Bacula} to {\bf hang} for some unknown reason.
187
To avoid this, you can use the {\bf RunAfterJob} command in the Job resource
188
to schedule a Job nightly, or weekly that simply emails you a message saying
189
that Bacula is still running. For example, I have setup the following Job in
190
my Director's configuration file:
196
Run = Level=Full sun-sat at 6:05
206
Schedule = "Watchdog"
207
RunAfterJob = "/home/kern/bacula/bin/watchdog %c %d"
215
File Retention = 1day
216
Job Retention = 1 month
222
Where I established a schedule to run the Job nightly. The Job itself is type
223
{\bf Admin} which means that it doesn't actually do anything, and I've defined
224
a FileSet, Pool, Storage, and Client, all of which are not really used (and
225
probably don't need to be specified). The key aspect of this Job is the
230
RunAfterJob = "/home/kern/bacula/bin/watchdog %c %d"
234
which runs my "watchdog" script. As an example, I have added the Job codes
235
\%c and \%d which will cause the Client name and the Director's name to be
236
passed to the script. For example, if the Client's name is {\bf Watchdog} and
237
the Director's name is {\bf main-dir} then referencing \$1 in the script would
238
get {\bf Watchdog} and referencing \$2 would get {\bf main-dir}. In this case,
239
having the script know the Client and Director's name is not really useful,
240
but in other situations it may be.
242
You can put anything in the watchdog script. In my case, I like to monitor the
243
size of my catalog to be sure that {\bf Bacula} is really pruning it. The
244
following is my watchdog script:
249
cd /home/kern/mysql/var/bacula
251
/home/kern/bacula/bin/bsmtp \
252
-f "\(Bacula\) abuse@whitehouse.com" -h mail.yyyy.com \
253
-s "Bacula running" abuse@whitehouse.com
257
If you just wish to send yourself a message, you can do it with:
262
cd /home/kern/mysql/var/bacula
263
/home/kern/bacula/bin/bsmtp \
264
-f "\(Bacula\) abuse@whitehouse.com" -h mail.yyyy.com \
265
-s "Bacula running" abuse@whitehouse.com <<END-OF-DATA
266
Bacula is still running!!!
271
\subsection*{Maintaining a Valid Bootstrap File}
273
\index[general]{Maintaining a Valid Bootstrap File }
274
\index[general]{File!Maintaining a Valid Bootstrap }
275
\addcontentsline{toc}{subsection}{Maintaining a Valid Bootstrap File}
278
\ilink{ WriteBootstrap}{writebootstrap} record in each of your
279
Director's Job resources, you can constantly maintain a
280
\ilink{bootstrap}{_ChapterStart43} file that will enable you to
281
recover the state of your system as of the last backup without having the
282
Bacula catalog. This permits you to more easily recover from a disaster that
283
destroys your Bacula catalog.
285
When a Job resource has a {\bf WriteBootstrap} record, Bacula will maintain
286
the designated file (normally on another system but mounted by NSF) with up to
287
date information necessary to restore your system. For example, in my
288
Director's configuration file, I have the following record:
292
Write Bootstrap = "/mnt/deuter/files/backup/client-name.bsr"
296
where I replace {\bf client-name} by the actual name of the client that is
297
being backed up. Thus, Bacula automatically maintains one file for each of my
298
clients. The necessary bootstrap information is appended to this file during
299
each {\bf Incremental} backup, and the file is totally rewritten during each
302
Note, one disadvantage of writing to an NFS mounted volume as I do is
303
that if the other machine goes down, the OS will wait forever on the fopen()
304
call that Bacula makes. As a consequence, Bacula will completely stall until
305
the machine exporting the NSF mounts comes back up. A possible solution to this
306
problem was provided by Andrew Hilborne, and consists of using the {\bf soft}
307
option instead of the {\bf hard} option when mounting the NFS volume, which is
308
typically done in {\bf /etc/fstab}/. The NFS documentation explains these
309
options in detail. However, I found that with the {\bf soft} option
310
NFS disconnected frequently causing even more problems.
312
If you are starting off in the middle of a cycle (i.e. with Incremental
313
backups) rather than at the beginning (with a Full backup), the {\bf
314
bootstrap} file will not be immediately valid as it must always have the
315
information from a Full backup as the first record. If you wish to synchronize
316
your bootstrap file immediately, you can do so by running a {\bf restore}
317
command for the client and selecting a full restore, but when the restore
318
command asks for confirmation to run the restore Job, you simply reply no,
319
then copy the bootstrap file that was written to the location specified on the
320
{\bf Write Bootstrap} record. The restore bootstrap file can be found in {\bf
321
restore.bsr} in the working directory that you defined. In the example given
322
below for the client {\bf rufus}, my input is shown in bold. Note, the JobId
323
output has been partially truncated to fit on the page here:
327
(in the Console program)
329
First you select one or more JobIds that contain files
330
to be restored. You will then be presented several methods
331
of specifying the JobIds. Then you will be allowed to
332
select which files from those JobIds are to be restored.
333
To select the JobIds, you have the following choices:
334
1: List last 20 Jobs run
335
2: List Jobs where a given File is saved
336
3: Enter list of JobIds to select
337
4: Enter SQL list command
338
5: Select the most recent backup for a client
340
Select item: (1-6): {\bf 5}
341
The defined Client resources are:
345
Select Client (File daemon) resource (1-3): {\bf 2}
346
The defined FileSet resources are:
348
Item 1 selected automatically.
349
+-------+------+-------+---------+---------+------+-------+------------+
350
| JobId | Levl | Files | StrtTim | VolName | File | SesId | VolSesTime |
351
+-------+------+-------+---------+---------+------+-------+------------+
352
| 2 | F | 84 | ... | test1 | 0 | 1 | 1035645259 |
353
+-------+------+-------+---------+---------+------+-------+------------+
354
You have selected the following JobId: 2
355
Building directory tree for JobId 2 ...
356
The defined Storage resources are:
358
Item 1 selected automatically.
359
You are now entering file selection mode where you add and
360
remove files to be restored. All files are initially added.
361
Enter "done" to leave this mode.
364
84 files selected to restore.
366
JobName: kernsrestore
367
Bootstrap: /home/kern/bacula/working/restore.bsr
368
Where: /tmp/bacula-restores
373
OK to run? (yes/mod/no): {\bf no}
376
{\bf cp ../working/restore.bsr /mnt/deuter/files/backup/rufus.bsr}
380
\subsection*{Rejected Volumes After a Crash}
381
\label{RejectedVolumes}
382
\index[general]{Crash!Rejected Volumes After a }
383
\index[general]{Rejected Volumes After a Crash }
384
\addcontentsline{toc}{subsection}{Rejected Volumes After a Crash}
386
Bacula keeps a count of the number of files on each Volume in its Catalog
387
database so that before appending to a tape, it can verify that the number of
388
files are correct, and thus prevent overwriting valid data. If the Director or
389
the Storage daemon crashes before the job has completed, the tape will contain
390
one more file than is noted in the Catalog, and the next time you attempt to
391
use the same Volume, Bacula will reject it due to a mismatch between the
392
physical tape (Volume) and the catalog.
394
The easiest solution to this problem is to label a new tape and start fresh.
395
If you wish to continue appending to the current tape, you can do so by using
396
the {\bf update} command in the console program to change the {\bf Volume
397
Files} entry in the catalog. A typical sequence of events would go like the
411
17-Jan-2003 16:45 rufus-dir: Start Backup JobId 13,
412
Job=kernsave.2003-01-17_16.45.46
413
17-Jan-2003 16:45 rufus-sd: Volume test01 previously written,
414
moving to end of data.
415
17-Jan-2003 16:46 rufus-sd: kernsave.2003-01-17_16.45.46 Error:
416
I cannot write on this volume because:
417
The number of files mismatch! Volume=11 Catalog=10
418
17-Jan-2003 16:46 rufus-sd: Job kernsave.2003-01-17_16.45.46 waiting.
419
Cannot find any appendable volumes.
420
Please use the "label" command to create a new Volume for:
427
(note, lines wrapped for presentation)
428
The key here is the line that reads:
432
The number of files mismatch! Volume=11 Catalog=10
436
It says that Bacula found eleven files on the volume, but that the catalog
437
says there should be ten. When you see this, you can be reasonably sure that
438
the SD was interrupted while writing before it had a chance to update the
439
catalog. As a consequence, you can just modify the catalog count to eleven,
440
and even if the catalog contains references to files saved in file 11,
441
everything will be OK and nothing will be lost. Note that if the SD had
442
written several file marks to the volume, the difference between the Volume
443
cound and the Catalog count could be larger than one, but this is unusual.
445
If on the other hand the catalog is marked as having more files than Bacula
446
found on the tape, you need to consider the possible negative consequences of
447
modifying the catalog. Please see below for a more complete discussion of
450
Continuing with the example of {\bf Volume = 11 Catalog = 10}, to enable to
451
Bacula to append to the tape, you do the following:
458
2: Pool from resource
459
3: Slots from autochanger
460
Choose catalog item to update (1-3): {\bf 1}
464
Select the Pool (1-2):
465
+-------+---------+--------+---------+-----------+------+----------+------+-----+
466
| MedId | VolName | MedTyp | VolStat | VolBytes | Last | VolReten | Recy | Slt |
467
+-------+---------+--------+---------+-----------+------+----------+------+-----+
468
| 1 | test01 | DDS-4 | Error | 352427156 | ... | 31536000 | 1 | 0 |
469
+-------+---------+--------+---------+-----------+------+----------+------+-----+
470
Enter MediaId or Volume name: {\bf 1}
474
(note table output truncated for presentation) First, you chose to update the
475
Volume parameters by entering a {\bf 1}. In the volume listing that follows,
476
notice how the VolStatus is {\bf Error}. We will correct that after changing
477
the Volume Files. Continuing, you respond 1,
481
Updating Volume "test01"
482
Parameters to modify:
484
2: Volume Retention Period
485
3: Volume Use Duration
486
4: Maximum Volume Jobs
487
5: Maximum Volume Files
488
6: Maximum Volume Bytes
494
Select parameter to modify (1-11): {\bf 9}
495
Warning changing Volume Files can result
496
in loss of data on your Volume
497
Current Volume Files is: 10
498
Enter new number of Files for Volume: {\bf 11}
499
New Volume Files is: 11
500
Updating Volume "test01"
501
Parameters to modify:
503
2: Volume Retention Period
504
3: Volume Use Duration
505
4: Maximum Volume Jobs
506
5: Maximum Volume Files
507
6: Maximum Volume Bytes
513
Select parameter to modify (1-10): {\bf 1}
517
Here, you have selected {\bf 9} in order to update the Volume Files, then you
518
changed it from {\bf 10} to {\bf 11}, and you now answer {\bf 1} to change the
523
Current Volume status is: Error
531
Choose new Volume Status (1-6): {\bf 1}
532
New Volume status is: Append
533
Updating Volume "test01"
534
Parameters to modify:
536
2: Volume Retention Period
537
3: Volume Use Duration
538
4: Maximum Volume Jobs
539
5: Maximum Volume Files
540
6: Maximum Volume Bytes
546
Select parameter to modify (1-11): {\bf 11}
551
At this point, you have changed the Volume Files from {\bf 10} to {\bf 11} to
552
account for the last file that was written but not updated in the database,
553
and you changed the Volume Status back to {\bf Append}.
555
This was a lot of words to describe something quite simple.
557
The {\bf Volume Files} option exists only in version 1.29 and later, and you
558
should be careful using it. Generally, if you set the value to that which
559
Bacula said is on the tape, you will be OK, especially if the value is one
560
more than what is in the catalog.
562
Now lets consider the case:
566
The number of files mismatch! Volume=10 Catalog=12
570
Here the Bacula found fewer files on the volume than what is marked in the
571
catalog. Now, in this case, you should hesitate a lot before modifying the count
572
in the catalog, because if you force the catalog from 12 to 10, Bacula will
573
start writing after the file 10 on the tape, possibly overwriting valid data,
574
and if you ever try to restore any of the files that the catalog has marked as
575
saved on Files 11 and 12, all chaos will break out. In this case, you will
576
probably be better off using a new tape. In fact, you might want to see what
577
files the catalog claims are actually stored on that Volume, and back them up
578
to another tape and recycle this tape.
580
\subsection*{Security Considerations}
582
\index[general]{Considerations!Security }
583
\index[general]{Security Considerations }
584
\addcontentsline{toc}{subsection}{Security Considerations}
586
Only the File daemon needs to run with root permission (so that it can access
587
all files). As a consequence, you may run your Director, Storage daemon, and
588
MySQL or PostgreSQL database server as non-root processes. Version 1.30 has
589
the {\bf -u} and the {\bf -g} options that allow you to specify a userid and
590
groupid on the command line to be used after Bacula starts.
592
As of version 1.33, thanks to Dan Langille, it is easier to configure the
593
Bacula Director and Storage daemon to run as non-root.
595
You should protect the Bacula port addresses (normally 9101, 9102, and 9103)
596
from outside access by a firewall or other means of protection to prevent
597
unauthorized use of your daemons.
599
You should ensure that the configuration files are not world readable since
600
they contain passwords that allow access to the daemons. Anyone who can access
601
the Director using a console program can restore any file from a backup
604
You should protect your Catalog database. If you are using SQLite, make sure
605
that the working directory is readable only by root (or your Bacula userid),
606
and ensure that {\bf bacula.db} has permissions {\bf -rw-r\verb:--:r\verb:--:} (i.e. 640) or
607
more strict. If you are using MySQL or PostgreSQL, please note that the Bacula
608
setup procedure leaves the database open to anyone. At a minimum, you should
609
assign the user {\bf bacula} a userid and add it to your Director's
610
configuration file in the appropriate Catalog resource.
612
\subsection*{Creating Holiday Schedules}
614
\index[general]{Schedules!Creating Holiday }
615
\index[general]{Creating Holiday Schedules }
616
\addcontentsline{toc}{subsection}{Creating Holiday Schedules}
618
If you normally change tapes every day or at least every Friday, but Thursday
619
is a holiday, you can use a trick proposed by Lutz Kittler to ensure that no
620
job runs on Thursday so that you can insert Friday's tape and be sure it will
621
be used on Friday. To do so, define a {\bf RunJobBefore} script that normally
622
returns zero, so that the Bacula job will normally continue. You can then
623
modify the script to return non-zero on any day when you do not want Bacula to
626
\subsection*{Automatic Labeling Using Your Autochanger}
628
\index[general]{Automatic Labeling Using Your Autochanger }
629
\index[general]{Autochanger!Automatic Labeling Using Your }
630
\addcontentsline{toc}{subsection}{Automatic Labeling Using Your Autochanger}
632
If you have an autochanger but it does not support barcodes, using a "trick"
633
you can make Bacula automatically label all the volumes in your autochanger's
636
First create a file containing one line for each slot in your autochanger that
637
has a tape to be labeled. The line will contain the slot number a colon (:)
638
then the Volume name you want to use. For example, create a file named {\bf
639
volume-list}, which contains:
649
The records do not need to be in any order and you don't need to mention all
650
the slots. Normally, you will have a consistent set of Volume names and a
651
sequential set of numbers for each slot you want labeled. In the example
652
above, I've left out slots 3 and 4 just as an example. Now, modify your {\bf
653
mtx-changer} script and comment out all the lines in the {\bf list)} case by
654
putting a \# in column 1. Then add the following two lines:
658
cat <absolute-path>/volume-list
663
so that the whole case looks like:
669
# commented out lines
670
cat <absolute-path>/volume-list
676
where you replace \lt{}absolute-path\gt{} with the full path to the
677
volume-list file. Then using the console, you enter the following command:
685
and Bacula will proceed to mount the autochanger Volumes in the list and label
686
them with the Volume names you have supplied. Bacula will think that the list
687
was provided by the autochanger barcodes, but in reality, it was you who
688
supplied the \lt{}barcodes\gt{}.
690
If it seems to work, when it finishes, enter:
698
and you should see all the volumes nicely created.
700
\subsection*{Backing Up Portables Using DHCP}
702
\index[general]{DHCP!Backing Up Portables Using }
703
\index[general]{Backing Up Portables Using DHCP }
704
\addcontentsline{toc}{subsection}{Backing Up Portables Using DHCP}
706
You may want to backup laptops or portables that are not always connected to
707
the network. If you are using DHCP to assign an IP address to those machines
708
when they connect, you will need to use the Dynamic Update capability of DNS
709
to assign a name to those machines that can be used in the Address field of
710
the Client resource in the Director's conf file.
712
\subsection*{Going on Vacation}
714
\index[general]{Vacation!Going on }
715
\index[general]{Going on Vacation }
716
\addcontentsline{toc}{subsection}{Going on Vacation}
718
At some point, you may want to be absent for a week or two and you want to
719
make sure Bacula has enough tape left so that the backups will complete. You
720
start by doing a {\bf list volumes} in the Console program:
726
Using default Catalog name=BackupDB DB=bacula
728
+---------+---------------+-----------+-----------+----------------+-
729
| MediaId | VolumeName | MediaType | VolStatus | VolBytes |
730
+---------+---------------+-----------+-----------+----------------+-
731
| 23 | DLT-30Nov02 | DLT8000 | Full | 54,739,278,128 |
732
| 24 | DLT-21Dec02 | DLT8000 | Full | 56,331,524,629 |
733
| 25 | DLT-11Jan03 | DLT8000 | Full | 67,863,514,895 |
734
| 26 | DLT-02Feb03 | DLT8000 | Full | 63,439,314,216 |
735
| 27 | DLT-03Mar03 | DLT8000 | Full | 66,022,754,598 |
736
| 28 | DLT-04Apr03 | DLT8000 | Full | 60,792,559,924 |
737
| 29 | DLT-28Apr03 | DLT8000 | Full | 62,072,494,063 |
738
| 30 | DLT-17May03 | DLT8000 | Full | 65,901,767,839 |
739
| 31 | DLT-07Jun03 | DLT8000 | Used | 56,558,490,015 |
740
| 32 | DLT-28Jun03 | DLT8000 | Full | 64,274,871,265 |
741
| 33 | DLT-19Jul03 | DLT8000 | Full | 64,648,749,480 |
742
| 34 | DLT-08Aug03 | DLT8000 | Full | 64,293,941,255 |
743
| 35 | DLT-24Aug03 | DLT8000 | Append | 9,999,216,782 |
744
+---------+---------------+-----------+-----------+----------------+
748
Note, I have truncated the output for presentation purposes. What is
749
significant, is that I can see that my current tape has almost 10 Gbytes of
750
data, and that the average amount of data I get on my tapes is about 60
751
Gbytes. So if I go on vacation now, I don't need to worry about tape capacity
752
(at least not for short absences).
754
Equally significant is the fact that I did go on vacation the 28th of June
755
2003, and when I did the {\bf list volumes} command, my current tape at that
756
time, DLT-07Jun03 MediaId 31, had 56.5 Gbytes written. I could see that the
757
tape would fill shortly. Consequently, I manually marked it as {\bf Used} and
758
replaced it with a fresh tape that I labeled as DLT-28Jun03, thus assuring
759
myself that the backups would all complete without my intervention.
761
\subsection*{How to Excude File on Windows Regardless of Case}
763
\index[general]{How to Excude File on Windows Regardless of Case }
764
\index[general]{Case!How to Excude File on Windows Regardless of }
765
\addcontentsline{toc}{subsection}{How to Excude File on Windows Regardless of
768
This tip was submitted by Marc Brueckner who wasn't sure of the case of some
769
of his files on Win32, which is case insensitive. The problem is that Bacula
770
thinks that {\bf /UNIMPORTANT FILES} is different from {\bf /Unimportant
771
Files}. Marc was aware that the file exclusion permits wild-cards. So, he
776
"/[Uu][Nn][Ii][Mm][Pp][Oo][Rr][Tt][Aa][Nn][Tt] [Ff][Ii][Ll][Ee][Ss]"
780
As a consequence, the above exclude works for files of any case.
782
Please note that this works only in Bacula Exclude statement and not in
785
\subsection*{Executing Scripts on a Remote Machine}
786
\label{RemoteExecution}
787
\index[general]{Machine!Executing Scripts on a Remote }
788
\index[general]{Executing Scripts on a Remote Machine }
789
\addcontentsline{toc}{subsection}{Executing Scripts on a Remote Machine}
791
This tip also comes from Marc Brueckner. (Note, this tip is probably outdated
792
by the addition of {\bf ClientRunBeforJob} and {\bf ClientRunAfterJob} Job
793
records, but the technique still could be useful.) First I thought the "Run
794
Before Job" statement in the Job-resource is for executing a script on the
795
remote machine(the machine to be backed up). It could be usefull to execute
796
scripts on the remote machine e.g. for stopping databases or other services
797
while doing the backup. (Of course I have to start the services again when the
798
backup has finished) I found the following solution: Bacula could execute
799
scrips on the remote machine by using ssh. The authentication is done
800
automatically using a private key. First You have to generate a keypair. I've
805
ssh-keygen -b 4096 -t dsa -f Bacula_key
809
This statement may take a little time to run. It creates a public/private key
810
pair with no passphrase. You could save the keys in /etc/bacula. Now you have
811
two new files : Bacula\_key which contains the private key and Bacula\_key.pub
812
which contains the public key.
814
Now you have to append the Bacula\_key.pub file to the file authorized\_keys
815
in the \textbackslash{}root\textbackslash{}.ssh directory of the remote
816
machine. Then you have to add (or uncomment) the line
820
AuthorizedKeysFile %h/.ssh/authorized_keys
824
to the sshd\_config file on the remote machine. Where the \%h stands for the
825
home-directory of the user (root in this case).
827
Assuming that your sshd is already running on the remote machine, you can now
828
enter the following on the machine where Bacula runs:
832
ssh -i Bacula_key -l root "ls -la"
836
This should execute the "ls -la" command on the remote machine.
838
Now you could add lines like the following to your Director's conf file:
843
Run Before Job = ssh -i /etc/bacula/Bacula_key 192.168.1.1 \
844
"/etc/init.d/database stop"
845
Run After Job = ssh -i /etc/bacula/Bacula_key 192.168.1.1 \
846
"/etc/init.d/database start"
851
Even though Bacula version 1.32 has a ClientRunBeforeJob, the ssh method still
852
could be useful for updating all the Bacula clients on several remote machines
855
\subsection*{Recycling All Your Volumes}
857
\index[general]{Recycling All Your Volumes }
858
\index[general]{Volumes!Recycling All Your }
859
\addcontentsline{toc}{subsection}{Recycling All Your Volumes}
861
This tip comes from Phil Stracchino.
863
If you decide to blow away your catalog and start over, the simplest way to
864
re-add all your prelabeled tapes with a minimum of fuss (provided you don't
865
care about the data on the tapes) is to add the tape labels using the console
866
{\bf add} command, then go into the catalog and manually set the VolStatus of
867
every tape to {\bf Recycle}.
869
The SQL command to do this is very simple:
873
update Media set VolStatus = "Recycle";
877
Bacula will then ignore the data already stored on the tapes and just re-use
878
each tape without further objection.
880
\subsection*{Backing up ACLs on ext3 or XFS filesystems}
882
\index[general]{Filesystems!Backing up ACLs on ext3 or XFS }
883
\index[general]{Backing up ACLs on ext3 or XFS filesystems }
884
\addcontentsline{toc}{subsection}{Backing up ACLs on ext3 or XFS filesystems}
886
This tip comes from Volker Sauer.
888
Note, this tip was given prior to implementation of ACLs in Bacula (version
889
1.34.5). It is left here because dumping/displaying ACLs can still be useful
890
in testing/verifying that Bacula is backing up and restoring your ACLs
891
properly. Please see the
892
\ilink{aclsupport}{ACLSupport} FileSet option in the
893
configuration chapter of this manual.
895
For example, you could dump the ACLs to a file with a script similar to the
901
BACKUP_DIRS="/foo /bar"
902
STORE_ACL=/root/acl-backup
904
for i in $BACKUP_DIRS; do
905
cd $i /usr/bin/getfacl -R --skip-base .>$STORE_ACL/${i//\//_}
910
Then use Bacula to backup {\bf /root/acl-backup}.
912
The ACLs could be restored using Bacula to the {\bf /root/acl-backup} file,
913
then restored to your system using:
917
setfacl --restore/root/acl-backup
921
\subsection*{Total Automation of Bacula Tape Handling}
923
\index[general]{Handling!Total Automation of Bacula Tape }
924
\index[general]{Total Automation of Bacula Tape Handling }
925
\addcontentsline{toc}{subsection}{Total Automation of Bacula Tape Handling}
927
This tip was provided by Alexander Kuehn.
929
\elink{Bacula}{http://www.bacula.org/} is a really nice backup program except
930
that the manual tape changing requires user interaction with the bacula
933
Fortunately I can fix this.
934
NOTE!!! This suggestion applies for people who do *NOT* have tape autochangers
935
and must change tapes manually.!!!!!
937
Bacula supports a variety of tape changers through the use of mtx-changer
938
scripts/programs. This highly flexible approach allowed me to create
939
\ilink{this shell script}{mtx-changer.txt} which does the following:
940
Whenever a new tape is required it sends a mail to the operator to insert the
941
new tape. Then it waits until a tape has been inserted, sends a mail again to
942
say thank you and let's bacula continue it's backup.
943
So you can schedule and run backups without ever having to log on or see the
945
To make the whole thing work you need to create a Device resource which looks
946
something like this ("Archive Device", "Maximum Changer Wait", "Media
947
Type" and "Label media" may have different values):
953
Archive Device = # use yours not mine! ;)/dev/nsa0
954
Changer Device = # not really required/dev/nsa0
955
Changer Command = "# use this (maybe change the path)!
956
/usr/local/bin/mtx-changer %o %a %S"
957
Maximum Changer Wait = 3d # 3 days in seconds
958
AutomaticMount = yes; # mount on start
959
AlwaysOpen = yes; # keep device locked
960
Media Type = DDS3 # it's just a name
961
RemovableMedia = yes; #
962
Offline On Unmount = Yes; # keep this too
968
As the script has to emulate the complete wisdom of a mtx-changer it has an
969
internal "database" containing where which tape is stored, you can see this on
974
labels="VOL-0001 VOL-0002 VOL-0003 VOL-0004 VOL-0005 VOL-0006
975
VOL-0007 VOL-0008 VOL-0009 VOL-0010 VOL-0011 VOL-0012"
979
The above should be all on one line, and it effectivly tells Bacula that
980
volume "VOL-0001" is located in slot 1 (which is our lowest slot), that
981
volume "VOL-0002" is located in slot 2 and so on..
982
The script also maintains a logfile (/var/log/mtx.log) where you can monitor
985
\subsection*{Running Concurrent Jobs}
986
\label{ConcurrentJobs}
987
\index[general]{Jobs!Running Concurrent}
988
\index[general]{Running Concurrent Jobs}
989
\index[general]{Concurrent Jobs}
990
\addcontentsline{toc}{subsection}{Running Concurrent Jobs}
992
Bacula can run multiple concurrent jobs, but the default configuration files
993
are not set to do so. Using the {\bf Maximum Concurrent Jobs} directive, you
994
have a lot of control over how many jobs can run at the same time, and which
995
jobs can run simultaneously. The downside is that it can be a bit tricky to
996
set it up for the first time as you need to set the concurrency in at least
997
five different places.
999
The Director, the File daemon, and the Storage daemon each have a {\bf Maximum
1000
Concurrent Jobs} directive that determines overall number of concurrent jobs
1001
the daemon will run. The default is one for the Director and ten for both the
1002
File daemon and the Storage daemon, so assuming you will not be running more
1003
than ten concurrent jobs, the only changes that are needed are in the
1004
Director's conf file (bacula-dir.conf).
1006
Within the Director's configuration file, {\bf Maximum Concurrent Jobs} can be
1007
set in the Direct, Job, Client, and Storage resources. Each one must be set
1008
properly, according to your needs, otherwise your jobs may be run one at a
1011
For example, if you want two different jobs to run simultaneously backing up
1012
the same Client to the same Storage device, they will run concurrentl only if
1013
you have set {\bf Maximum Concurrent Jobs} greater than one in the Director
1014
resource, the Client resource, and the Storage resource in bacula-dir.conf.
1016
We recommend that you carefully test your multiple concurrent backup including
1017
doing thorough restore testing before you put it into production.
1019
Below is a super stripped down bacula-dir.conf file showing you the four
1020
places where the the file has been modified to allow the same job {\bf
1021
NightlySave} to run up to four times concurrently. The change to the Job
1022
resource is not necessary if you want different Jobs to run at the same time,
1023
which is the normal case.
1028
# Bacula Director Configuration file -- bacula-dir.conf
1032
Maximum Concurrent Jobs = 4
1036
Name = "NightlySave"
1037
Maximum Concurrent Jobs = 4
1044
Maximum Concurrent Jobs = 4
1049
Maximum Concurrent Jobs = 4
added
removed
manual-fr/tips.tex
