Next: Customizing the Configuration Files Up: Main Reference Previous: Critical Items to Implement Contents Index
This chapter will guide you through running Bacula. To do so, we assume you have installed Bacula, possibly in a single file as shown in the previous chapter, in which case, you can run Bacula as non-root for these tests. However, we assume that you have not changed the .conf files. If you have modified the .conf files, please go back and uninstall Bacula, then reinstall it, but do not make any changes. The examples in this chapter use the default configuration files, and will write the volumes to disk in your /tmp directory, in addition, the data backed up will be the source directory where you built Bacula. As a consequence, you can run all the Bacula daemons for these tests as non-root. Please note, in production, your File daemon(s) must run as root. See the Security chapter for more information on this subject.
The general flow of running Bacula is:
Each of these steps is described in more detail below.
Before running Bacula for the first time in production, we recommend that you run the test command in the btape program as described in the Utility Programbtapeutilitychapter of the Bacula Enterprise Utility programs. This will help ensure that Bacula functions correctly with your tape drive. If you have a modern HP, Sony, or Quantum DDS or DLT tape drive running on Linux or Solaris, you can probably skip this test as Bacula is well tested with these drives and systems. For all other cases, you are strongly encouraged to run the test before continuing. btape also has a fill command that attempts to duplicate what Bacula does when filling a tape and writing on the next tape. You should consider trying this command as well, but be forewarned, it can take hours (about four hours on my drive) to fill a large capacity tape.
If you are using MySQL or PostgreSQL as the Bacula database, you should start it before you attempt to run a job to avoid getting error messages from Bacula when it starts. Normally if you have installed the MySQL or PostgreSQL packages, the database server will automatically restart when your system is booted. In any case you must start the database server prior to starting the Bacula Director.
Assuming you have built from source or have installed the rpms, to start the three daemons, from your installation directory, simply enter:
./bacula start
The bacula script starts the Storage daemon, the File daemon, and the Director daemon, which all normally run as daemons in the background. If you are using the autostart feature of Bacula, your daemons will either be automatically started on reboot, or you can control them individually with the files bacula-dir, bacula-fd, and bacula-sd, which are usually located in /etc/init.d, though the actual location is system dependent. Some distributions may do this differently.
Note, on Windows, currently only the File daemon is ported, and it must be started differently. Please see the Windows Version of BaculaWin32Chapter Chapter of this manual.
The rpm packages configure the daemons to run as user=root and group=bacula. The rpm installation also creates the group bacula if it does not exist on the system. Any users that you add to the group bacula will have access to files created by the daemons. To disable or alter this behavior edit the daemon startup scripts:
and then restart as noted above.
The installation chapterInstallChapter of this manual explains how you can install scripts that will automatically restart the daemons when the system starts.
To communicate with the director and to query the state of Bacula or run jobs, from the top level directory, simply enter:
./bconsole
Alternatively to running the command line console, if you have Qt4 installed and used the --enable-bat on the configure command, you may use the Bacula Administration Tool (bat):
./bat
Which has a graphical interface, and many more features than bconsole.
Two other possibilities are to run the GNOME console bgnome-console or the wxWidgets program bwx-console.
For simplicity, here we will describe only the ./bconsole program. Most of what is described here applies equally well to ./bat, ./bgnome-console, and to bwx-console.
The ./bconsole runs the Bacula Console program, which connects to the Director daemon. Since Bacula is a network program, you can run the Console program anywhere on your network. Most frequently, however, one runs it on the same machine as the Director. Normally, the Console program will print something similar to the following:
[kern@polymatou bin]$ ./bconsole Connecting to Director lpmatou:9101 1000 OK: HeadMan Version: 2.1.8 (14 May 2007) *
the asterisk is the console command prompt.
Type help to see a list of available commands:
*help Command Description ======= =========== add add media to a pool autodisplay autodisplay [on|off] -- console messages automount automount [on|off] -- after label cancel cancel [<jobid=nnn> | <job=name>] -- cancel a job create create DB Pool from resource delete delete [pool=<pool-name> | media volume=<volume-name>] disable disable <job=name> -- disable a job enable enable <job=name> -- enable a job estimate performs FileSet estimate, listing gives full listing exit exit = quit gui gui [on|off] -- non-interactive gui mode help print this command list list [pools | jobs | jobtotals | media <pool=pool-name> | files <jobid=nn>]; from catalog label label a tape llist full or long list like list command memory print current memory usage messages messages mount mount <storage-name> prune prune expired records from catalog purge purge records from catalog quit quit query query catalog restore restore files relabel relabel a tape release release <storage-name> reload reload conf file run run <job-name> status status [[slots] storage | dir | client]=<name> setdebug sets debug level setip sets new client address -- if authorized show show (resource records) [jobs | pools | ... | all] sqlquery use SQL to query catalog time print current time trace turn on/off trace to file unmount unmount <storage-name> umount umount <storage-name> for old-time Unix guys update update Volume, Pool or slots use use catalog xxx var does variable expansion version print Director version wait wait until no jobs are running [<jobname=name> | <jobid=nnn> | <ujobid=complete_name>] *
Details of the console program's commands are explained in the ConsoleTheConsoleChapterconsolechapter of the Bacula Enterprise Console Manual.
At this point, we assume you have done the following:
--your-optionsFurthermore, we assume for the moment you are using the default configuration files.
At this point, enter the following command:
show filesets
and you should get something similar to:
FileSet: name=Full Set
O M
N
I /home/kern/bacula/regress/build
N
E /proc
E /tmp
E /.journal
E /.fsck
N
FileSet: name=Catalog
O M
N
I /home/kern/bacula/regress/working/bacula.sql
N
This is a pre-defined FileSet that will backup the Bacula source directory. The actual directory names printed should correspond to your system configuration. For testing purposes, we have chosen a directory of moderate size (about 40 Megabytes) and complexity without being too big. The FileSet Catalog is used for backing up Bacula's catalog and is not of interest to us for the moment. The I entries are the files or directories that will be included in the backup and the E are those that will be excluded, and the O entries are the options specified for the FileSet. You can change what is backed up by editing bacula-dir.conf and changing the File = line in the FileSet resource.
Now is the time to run your first backup job. We are going to backup your Bacula source directory to a File Volume in your /tmp directory just to show you how easy it is. Now enter:
status dir
and you should get the following output:
rufus-dir Version: 1.30 (28 April 2003) Daemon started 28-Apr-2003 14:03, 0 Jobs run. Console connected at 28-Apr-2003 14:03 No jobs are running. Level Type Scheduled Name ================================================================= Incremental Backup 29-Apr-2003 01:05 Client1 Full Backup 29-Apr-2003 01:10 BackupCatalog ====
where the times and the Director's name will be different according to your setup. This shows that an Incremental job is scheduled to run for the Job Client1 at 1:05am and that at 1:10, a BackupCatalog is scheduled to run. Note, you should probably change the name Client1 to be the name of your machine, if not, when you add additional clients, it will be very confusing. For my real machine, I use Rufus rather than Client1 as in this example.
Now enter:
status client
and you should get something like:
The defined Client resources are:
1: rufus-fd
Item 1 selected automatically.
Connecting to Client rufus-fd at rufus:8102
rufus-fd Version: 1.30 (28 April 2003)
Daemon started 28-Apr-2003 14:03, 0 Jobs run.
Director connected at: 28-Apr-2003 14:14
No jobs running.
====
In this case, the client is named rufus-fd your name will be different, but the line beginning with rufus-fd Version ... is printed by your File daemon, so we are now sure it is up and running.
Finally do the same for your Storage daemon with:
status storage
and you should get:
The defined Storage resources are:
1: File
Item 1 selected automatically.
Connecting to Storage daemon File at rufus:8103
rufus-sd Version: 1.30 (28 April 2003)
Daemon started 28-Apr-2003 14:03, 0 Jobs run.
Device /tmp is not open.
No jobs running.
====
You will notice that the default Storage daemon device is named File and that it will use device /tmp, which is not currently open.
Now, let's actually run a job with:
run
you should get the following output:
Using default Catalog name=MyCatalog DB=bacula
A job name must be specified.
The defined Job resources are:
1: Client1
2: BackupCatalog
3: RestoreFiles
Select Job resource (1-3):
Here, Bacula has listed the three different Jobs that you can run, and you should choose number 1 and type enter, at which point you will get:
Run Backup job JobName: Client1 FileSet: Full Set Level: Incremental Client: rufus-fd Storage: File Pool: Default When: 2003-04-28 14:18:57 OK to run? (yes/mod/no):
At this point, take some time to look carefully at what is printed and understand it. It is asking you if it is OK to run a job named Client1 with FileSet Full Set (we listed above) as an Incremental job on your Client (your client name will be different), and to use Storage File and Pool Default, and finally, it wants to run it now (the current time should be displayed by your console).
Here we have the choice to run (yes), to modify one or more of the above parameters (mod), or to not run the job (no). Please enter yes, at which point you should immediately get the command prompt (an asterisk). If you wait a few seconds, then enter the command messages you will get back something like:
28-Apr-2003 14:22 rufus-dir: Last FULL backup time not found. Doing
FULL backup.
28-Apr-2003 14:22 rufus-dir: Start Backup JobId 1,
Job=Client1.2003-04-28_14.22.33
28-Apr-2003 14:22 rufus-sd: Job Client1.2003-04-28_14.22.33 waiting.
Cannot find any appendable volumes.
Please use the "label" command to create a new Volume for:
Storage: FileStorage
Media type: File
Pool: Default
The first message, indicates that no previous Full backup was done, so Bacula is upgrading our Incremental job to a Full backup (this is normal). The second message indicates that the job started with JobId 1., and the third message tells us that Bacula cannot find any Volumes in the Pool for writing the output. This is normal because we have not yet created (labeled) any Volumes. Bacula indicates to you all the details of the volume it needs.
At this point, the job is BLOCKED waiting for a Volume. You can check this if you want by doing a status dir. In order to continue, we must create a Volume that Bacula can write on. We do so with:
label
and Bacula will print:
The defined Storage resources are:
1: File
Item 1 selected automatically.
Enter new Volume name:
at which point, you should enter some name beginning with a letter and containing only letters and numbers (period, hyphen, and underscore) are also permitted. For example, enter TestVolume001, and you should get back:
Defined Pools:
1: Default
Item 1 selected automatically.
Connecting to Storage daemon File at rufus:8103 ...
Sending label command for Volume "TestVolume001" Slot 0 ...
3000 OK label. Volume=TestVolume001 Device=/tmp
Catalog record for Volume "TestVolume002", Slot 0 successfully created.
Requesting mount FileStorage ...
3001 OK mount. Device=/tmp
Finally, enter messages and you should get something like:
28-Apr-2003 14:30 rufus-sd: Wrote label to prelabeled Volume "TestVolume001" on device /tmp 28-Apr-2003 14:30 rufus-dir: Bacula 1.30 (28Apr03): 28-Apr-2003 14:30 JobId: 1 Job: Client1.2003-04-28_14.22.33 FileSet: Full Set Backup Level: Full Client: rufus-fd Start time: 28-Apr-2003 14:22 End time: 28-Apr-2003 14:30 Files Written: 1,444 Bytes Written: 38,988,877 Rate: 81.2 KB/s Software Compression: None Volume names(s): TestVolume001 Volume Session Id: 1 Volume Session Time: 1051531381 Last Volume Bytes: 39,072,359 FD termination status: OK SD termination status: OK Termination: Backup OK 28-Apr-2003 14:30 rufus-dir: Begin pruning Jobs. 28-Apr-2003 14:30 rufus-dir: No Jobs found to prune. 28-Apr-2003 14:30 rufus-dir: Begin pruning Files. 28-Apr-2003 14:30 rufus-dir: No Files found to prune. 28-Apr-2003 14:30 rufus-dir: End auto prune.
If you don't see the output immediately, you can keep entering messages until the job terminates, or you can enter, autodisplay on and your messages will automatically be displayed as soon as they are ready.
If you do an ls -l of your /tmp directory, you will see that you have the following item:
-rw-r----- 1 kern kern 39072153 Apr 28 14:30 TestVolume001
This is the file Volume that you just wrote and it contains all the data of the job just run. If you run additional jobs, they will be appended to this Volume unless you specify otherwise.
You might ask yourself if you have to label all the Volumes that Bacula is going to use. The answer for disk Volumes, like the one we used, is no. It is possible to have Bacula automatically label volumes. For tape Volumes, you will most likely have to label each of the Volumes you want to use.
If you would like to stop here, you can simply enter quit in the Console program, and you can stop Bacula with ./bacula stop. To clean up, simply delete the file /tmp/TestVolume001, and you should also re-initialize your database using:
./drop_bacula_tables ./make_bacula_tables
Please note that this will erase all information about the previous jobs that have run, and that you might want to do it now while testing but that normally you will not want to re-initialize your database.
If you would like to try restoring the files that you just backed up, read the following section.
If you have run the default configuration and the save of the Bacula source code as demonstrated above, you can restore the backed up files in the Console program by entering:
restore all
where you will get:
First you select one or more JobIds that contain files
to be restored. You will be presented several methods
of specifying the JobIds. Then you will be allowed to
select which files from those JobIds are to be restored.
To select the JobIds, you have the following choices:
1: List last 20 Jobs run
2: List Jobs where a given File is saved
3: Enter list of comma separated JobIds to select
4: Enter SQL list command
5: Select the most recent backup for a client
6: Select backup for a client before a specified time
7: Enter a list of files to restore
8: Enter a list of files to restore before a specified time
9: Find the JobIds of the most recent backup for a client
10: Find the JobIds for a backup for a client before a specified time
11: Enter a list of directories to restore for found JobIds
12: Cancel
Select item: (1-12):
As you can see, there are a number of options, but for the current demonstration, please enter 5 to do a restore of the last backup you did, and you will get the following output:
Defined Clients:
1: rufus-fd
Item 1 selected automatically.
The defined FileSet resources are:
1: 1 Full Set 2003-04-28 14:22:33
Item 1 selected automatically.
+-------+-------+----------+---------------------+---------------+
| JobId | Level | JobFiles | StartTime | VolumeName |
+-------+-------+----------+---------------------+---------------+
| 1 | F | 1444 | 2003-04-28 14:22:33 | TestVolume002 |
+-------+-------+----------+---------------------+---------------+
You have selected the following JobId: 1
Building directory tree for JobId 1 ...
1 Job inserted into the tree and marked for extraction.
The defined Storage resources are:
1: File
Item 1 selected automatically.
You are now entering file selection mode where you add and
remove files to be restored. All files are initially added.
Enter "done" to leave this mode.
cwd is: /
$
where I have truncated the listing on the right side to make it more readable. As you can see by starting at the top of the listing, Bacula knows what client you have, and since there was only one, it selected it automatically, likewise for the FileSet. Then Bacula produced a listing containing all the jobs that form the current backup, in this case, there is only one, and the Storage daemon was also automatically chosen. Bacula then took all the files that were in Job number 1 and entered them into a directory tree (a sort of in memory representation of your filesystem). At this point, you can use the cd and ls ro dir commands to walk up and down the directory tree and view what files will be restored. For example, if I enter cd /home/kern/bacula/bacula-1.30 and then enter dir I will get a listing of all the files in the Bacula source directory. On your system, the path will be somewhat different. For more information on this, please refer to the Restore Command ChapterRestoreChapter of this manual for more details.
To exit this mode, simply enter:
done
and you will get the following output:
Bootstrap records written to /home/kern/bacula/testbin/working/restore.bsr The restore job will require the following Volumes: TestVolume001 1444 files selected to restore. Run Restore job JobName: RestoreFiles Bootstrap: /home/kern/bacula/testbin/working/restore.bsr Where: /tmp/bacula-restores Replace: always FileSet: Full Set Backup Client: rufus-fd Restore Client: rufus-fd Storage: File JobId: *None* When: 2005-04-28 14:53:54 OK to run? (yes/mod/no):
If you answer yes your files will be restored to /tmp/bacula-restores. If you want to restore the files to their original locations, you must use the mod option and explicitly set Where: to nothing (or to /). We recommend you go ahead and answer yes and after a brief moment, enter messages, at which point you should get a listing of all the files that were restored as well as a summary of the job that looks similar to this:
28-Apr-2005 14:56 rufus-dir: Bacula 2.1.8 (08May07): 08-May-2007 14:56:06 Build OS: i686-pc-linux-gnu suse 10.2 JobId: 2 Job: RestoreFiles.2007-05-08_14.56.06 Restore Client: rufus-fd Start time: 08-May-2007 14:56 End time: 08-May-2007 14:56 Files Restored: 1,444 Bytes Restored: 38,816,381 Rate: 9704.1 KB/s FD Errors: 0 FD termination status: OK SD termination status: OK Termination: Restore OK 08-May-2007 14:56 rufus-dir: Begin pruning Jobs. 08-May-2007 14:56 rufus-dir: No Jobs found to prune. 08-May-2007 14:56 rufus-dir: Begin pruning Files. 08-May-2007 14:56 rufus-dir: No Files found to prune. 08-May-2007 14:56 rufus-dir: End auto prune.
After exiting the Console program, you can examine the files in /tmp/bacula-restores, which will contain a small directory tree with all the files. Be sure to clean up at the end with:
rm -rf /tmp/bacula-restore
Simply enter the command quit.
If you have gotten the example shown above to work on your system, you may be ready to add a second Client (File daemon). That is you have a second machine that you would like backed up. The only part you need installed on the other machine is the binary bacula-fd (or bacula-fd.exe for Windows) and its configuration file bacula-fd.conf. You can start with the same bacula-fd.conf file that you are currently using and make one minor modification to it to create the conf file for your second client. Change the File daemon name from whatever was configured, rufus-fd in the example above, but your system will have a different name. The best is to change it to the name of your second machine. For example:
...
#
# "Global" File daemon configuration specifications
#
FileDaemon { # this is me
Name = rufus-fd
FDport = 9102 # where we listen for the director
WorkingDirectory = /home/kern/bacula/working
Pid Directory = /var/run
}
...
would become:
...
#
# "Global" File daemon configuration specifications
#
FileDaemon { # this is me
Name = matou-fd
FDport = 9102 # where we listen for the director
WorkingDirectory = /home/kern/bacula/working
Pid Directory = /var/run
}
...
where I show just a portion of the file and have changed rufus-fd to matou-fd. The names you use are your choice. For the moment, I recommend you change nothing else. Later, you will want to change the password.
Now you should install that change on your second machine. Then you need to make some additions to your Director's configuration file to define the new File daemon or Client. Starting from our original example which should be installed on your system, you should add the following lines (essentially copies of the existing data but with the names changed) to your Director's configuration file bacula-dir.conf.
#
# Define the main nightly save backup job
# By default, this job will back up to disk in /tmp
Job {
Name = "Matou"
Type = Backup
Client = matou-fd
FileSet = "Full Set"
Schedule = "WeeklyCycle"
Storage = File
Messages = Standard
Pool = Default
Write Bootstrap = "/home/kern/bacula/working/matou.bsr"
}
# Client (File Services) to backup
Client {
Name = matou-fd
Address = matou
FDPort = 9102
Catalog = MyCatalog
Password = "xxxxx" # password for
File Retention = 30d # 30 days
Job Retention = 180d # six months
AutoPrune = yes # Prune expired Jobs/Files
}
Then make sure that the Address parameter in the Storage resource is set to the fully qualified domain name and not to something like "localhost". The address specified is sent to the File daemon (client) and it must be a fully qualified domain name. If you pass something like "localhost" it will not resolve correctly and will result in a time out when the File daemon fails to connect to the Storage daemon.
That is all that is necessary. I copied the existing resource to create a second Job (Matou) to backup the second client (matou-fd). It has the name Matou, the Client is named matou-fd, and the bootstrap file name is changed, but everything else is the same. This means that Matou will be backed up on the same schedule using the same set of tapes. You may want to change that later, but for now, let's keep it simple.
The second change was to add a new Client resource that defines matou-fd and has the correct address matou, but in real life, you may need a fully qualified domain name or an IP address. I also kept the password the same (shown as xxxxx for the example).
At this point, if you stop Bacula and restart it, and start the Client on the other machine, everything will be ready, and the prompts that you saw above will now include the second machine.
To make this a real production installation, you will possibly want to use different Pool, or a different schedule. It is up to you to customize. In any case, you should change the password in both the Director's file and the Client's file for additional security.
For some important tips on changing names and passwords, and a diagram of what names and passwords must match, please see Authorization ErrorsAuthorizationErrorsproblemschapter in the Bacula Enterprise Problem Resolution Guide.
If you have scheduled your job, typically nightly, there will come a time when the tape fills up and Bacula cannot continue. In this case, Bacula will send you a message similar to the following:
rufus-sd: block.c:337 === Write error errno=28: ERR=No space left
on device
This indicates that Bacula got a write error because the tape is full. Bacula will then search the Pool specified for your Job looking for an appendable volume. In the best of all cases, you will have properly set your Retention Periods and you will have all your tapes marked to be Recycled, and Bacula will automatically recycle the tapes in your pool requesting and overwriting old Volumes. For more information on recycling, please see the Recycling chapterRecyclingChapter of this manual. If you find that your Volumes were not properly recycled (usually because of a configuration error), please see the Manually Recycling Volumesmanualrecycling section of the Recycling chapter.
If like me, you have a very large set of Volumes and you label them with the date the Volume was first writing, or you have not set up your Retention periods, Bacula will not find a tape in the pool, and it will send you a message similar to the following:
rufus-sd: Job kernsave.2002-09-19.10:50:48 waiting. Cannot find any
appendable volumes.
Please use the "label" command to create a new Volume for:
Storage: SDT-10000
Media type: DDS-4
Pool: Default
Until you create a new Volume, this message will be repeated an hour later, then two hours later, and so on doubling the interval each time up to a maximum interval of one day.
The obvious question at this point is: What do I do now?
The answer is simple: first, using the Console program, close the tape drive using the unmount command. If you only have a single drive, it will be automatically selected, otherwise, make sure you release the one specified on the message (in this case STD-10000).
Next, you remove the tape from the drive and insert a new blank tape. Note, on some older tape drives, you may need to write an end of file mark (mt -f /dev/nst0 weof) to prevent the drive from running away when Bacula attempts to read the label.
Finally, you use the label command in the Console to write a label to the new Volume. The label command will contact the Storage daemon to write the software label, if it is successful, it will add the new Volume to the Pool, then issue a mount command to the Storage daemon. See the previous sections of this chapter for more details on labeling tapes.
The result is that Bacula will continue the previous Job writing the backup to the new Volume.
If you have a Pool of volumes and Bacula is cycling through them, instead of the above message "Cannot find any appendable volumes.", Bacula may ask you to mount a specific volume. In that case, you should attempt to do just that. If you do not have the volume any more (for any of a number of reasons), you can simply mount another volume from the same Pool, providing it is appendable, and Bacula will use it. You can use the list volumes command in the console program to determine which volumes are appendable and which are not.
If like me, you have your Volume retention periods set correctly, but you have no more free Volumes, you can relabel and reuse a Volume as follows:
To manually relabel the Volume use the following additional steps:
Most of the commands given above, with the exception of list, will prompt you for the necessary arguments if you simply enter the command name.
If you want debug output from the daemons as they are running, start the daemons from the install directory as follows:
./bacula start -d100
This can be particularly helpful if your daemons do not start correctly, because direct daemon output to the console is normally directed to the NULL device, but with the debug level greater than zero, the output will be sent to the starting terminal.
To stop the three daemons, enter the following from the install directory:
./bacula stop
The execution of bacula stop may complain about pids not found. This is OK, especially if one of the daemons has died, which is very rare.
To do a full system save, each File daemon must be running as root so that it will have permission to access all the files. None of the other daemons require root privileges. However, the Storage daemon must be able to open the tape drives. On many systems, only root can access the tape drives. Either run the Storage daemon as root, or change the permissions on the tape devices to permit non-root access. MySQL and PostgreSQL can be installed and run with any userid; root privilege is not necessary.
When you start the Bacula daemons, the Storage daemon attempts to open all defined storage devices and verify the currently mounted Volume (if configured). Until all the storage devices are verified, the Storage daemon will not accept connections from the Console program. If a tape was previously used, it will be rewound, and on some devices this can take several minutes. As a consequence, you may need to have a bit of patience when first contacting the Storage daemon after starting the daemons. If you can see your tape drive, once the lights stop flashing, the drive will be ready to be used.
The same considerations apply if you have just mounted a blank tape in a drive such as an HP DLT. It can take a minute or two before the drive properly recognizes that the tape is blank. If you attempt to mount the tape with the Console program during this recognition period, it is quite possible that you will hang your SCSI driver (at least on my Red Hat Linux system). As a consequence, you are again urged to have patience when inserting blank tapes. Let the device settle down before attempting to access it.
If you are having difficulties getting one or more of your File daemons to connect to the Storage daemon, it is most likely because you have not used a fully qualified domain name on the Address directive in the Director's Storage resource. That is the resolver on the File daemon's machine (not on the Director's) must be able to resolve the name you supply into an IP address. An example of an address that is guaranteed not to work: localhost. An example that may work: megalon. An example that is more likely to work: magalon.mydomain.com. On Win32 if you don't have a good resolver (often true on older Win98 systems), you might try using an IP address in place of a name.
If your address is correct, then make sure that no other program is using the port 9103 on the Storage daemon's machine. The Bacula port numbers are authorized by IANA, and should not be used by other programs, but apparently some HP printers do use these port numbers. A netstat -a on the Storage daemon's machine can determine who is using the 9103 port (used for FD to SD communications in Bacula).
Each of the three daemons (Director, File, Storage) accepts a small set of options on the command line. In general, each of the daemons as well as the Console program accepts the following options:
Creating the Pool is automatically done when Bacula starts, so if you understand Pools, you can skip to the next section.
When you run a job, one of the things that Bacula must know is what Volumes to use to backup the FileSet. Instead of specifying a Volume (tape) directly, you specify which Pool of Volumes you want Bacula to consult when it wants a tape for writing backups. Bacula will select the first available Volume from the Pool that is appropriate for the Storage device you have specified for the Job being run. When a volume has filled up with data, Bacula will change its VolStatus from Append to Full, and then Bacula will use the next volume and so on. If no appendable Volume exists in the Pool, the Director will attempt to recycle an old Volume, if there are still no appendable Volumes available, Bacula will send a message requesting the operator to create an appropriate Volume.
Bacula keeps track of the Pool name, the volumes contained in the Pool, and a number of attributes of each of those Volumes.
When Bacula starts, it ensures that all Pool resource definitions have been recorded in the catalog. You can verify this by entering:
list pools
to the console program, which should print something like the following:
*list pools Using default Catalog name=MySQL DB=bacula +--------+---------+---------+---------+----------+-------------+ | PoolId | Name | NumVols | MaxVols | PoolType | LabelFormat | +--------+---------+---------+---------+----------+-------------+ | 1 | Default | 3 | 0 | Backup | * | | 2 | File | 12 | 12 | Backup | File | +--------+---------+---------+---------+----------+-------------+ *
If you attempt to create the same Pool name a second time, Bacula will print:
Error: Pool Default already exists.
Once created, you may use the {\bf update} command to
modify many of the values in the Pool record.
Bacula requires that each Volume contains a software label. There are several strategies for labeling volumes. The one I use is to label them as they are needed by Bacula using the console program. That is when Bacula needs a new Volume, and it does not find one in the catalog, it will send me an email message requesting that I add Volumes to the Pool. I then use the label command in the Console program to label a new Volume and to define it in the Pool database, after which Bacula will begin writing on the new Volume. Alternatively, I can use the Console relabel command to relabel a Volume that is no longer used providing it has VolStatus Purged.
Another strategy is to label a set of volumes at the start, then use them as Bacula requests them. This is most often done if you are cycling through a set of tapes, for example using an autochanger. For more details on recycling, please see the Automatic Volume RecyclingRecyclingChapter chapter of this manual.
If you run a Bacula job, and you have no labeled tapes in the Pool, Bacula will inform you, and you can create them "on-the-fly" so to speak. In my case, I label my tapes with the date, for example: DLT-18April02. See below for the details of using the label command.
Labeling volumes is normally done by using the console program.
If Bacula complains that you cannot label the tape because it is already labeled, simply unmount the tape using the unmount command in the console, then physically mount a blank tape and re-issue the label command.
Since the physical storage media is different for each device, the label command will provide you with a list of the defined Storage resources such as the following:
The defined Storage resources are:
1: File
2: 8mmDrive
3: DLTDrive
4: SDT-10000
Select Storage resource (1-4):
At this point, you should have a blank tape in the drive corresponding to the Storage resource that you select.
It will then ask you for the Volume name.
Enter new Volume name:
If Bacula complains:
Media record for Volume xxxx already exists.
It means that the volume name xxxx that you entered already exists in the Media database. You can list all the defined Media (Volumes) with the list media command. Note, the LastWritten column has been truncated for proper printing.
+---------------+---------+--------+----------------+-----/~/-+------------+-----+ | VolumeName | MediaTyp| VolStat| VolBytes | LastWri | VolReten | Recy| +---------------+---------+--------+----------------+---------+------------+-----+ | DLTVol0002 | DLT8000 | Purged | 56,128,042,217 | 2001-10 | 31,536,000 | 0 | | DLT-07Oct2001 | DLT8000 | Full | 56,172,030,586 | 2001-11 | 31,536,000 | 0 | | DLT-08Nov2001 | DLT8000 | Full | 55,691,684,216 | 2001-12 | 31,536,000 | 0 | | DLT-01Dec2001 | DLT8000 | Full | 55,162,215,866 | 2001-12 | 31,536,000 | 0 | | DLT-28Dec2001 | DLT8000 | Full | 57,888,007,042 | 2002-01 | 31,536,000 | 0 | | DLT-20Jan2002 | DLT8000 | Full | 57,003,507,308 | 2002-02 | 31,536,000 | 0 | | DLT-16Feb2002 | DLT8000 | Full | 55,772,630,824 | 2002-03 | 31,536,000 | 0 | | DLT-12Mar2002 | DLT8000 | Full | 50,666,320,453 | 1970-01 | 31,536,000 | 0 | | DLT-27Mar2002 | DLT8000 | Full | 57,592,952,309 | 2002-04 | 31,536,000 | 0 | | DLT-15Apr2002 | DLT8000 | Full | 57,190,864,185 | 2002-05 | 31,536,000 | 0 | | DLT-04May2002 | DLT8000 | Full | 60,486,677,724 | 2002-05 | 31,536,000 | 0 | | DLT-26May02 | DLT8000 | Append | 1,336,699,620 | 2002-05 | 31,536,000 | 1 | +---------------+---------+--------+----------------+-----/~/-+------------+-----+
Once Bacula has verified that the volume does not already exist, it will prompt you for the name of the Pool in which the Volume (tape) is to be created. If there is only one Pool (Default), it will be automatically selected.
If the tape is successfully labeled, a Volume record will also be created in the Pool. That is the Volume name and all its other attributes will appear when you list the Pool. In addition, that Volume will be available for backup if the MediaType matches what is requested by the Storage daemon.
When you labeled the tape, you answered very few questions about it – principally the Volume name, and perhaps the Slot. However, a Volume record in the catalog database (internally known as a Media record) contains quite a few attributes. Most of these attributes will be filled in from the default values that were defined in the Pool (i.e. the Pool holds most of the default attributes used when creating a Volume).
It is also possible to add media to the pool without physically labeling the Volumes. This can be done with the add command. For more information, please see the ConsoleTheConsoleChapterconsolechapter of the Bacula Enterprise Console Manual.