Database Setup / Reset
The official Bacula documentation covers database setup and reset, should you wish to start again with a fresh database after your initial testing.
Before you use Bacula, you need to create and define its database tables. Bacula comes with scripts to do just that. On my FreeBSD system, these files are under the port directory. Because I'm sitting in Second Cup, using my laptop, I prefer to use SQLite, instead of MySQL.
# cd /usr/ports/sysutils/bacula/work/bacula-1.32c/src/cats # ./make_sqlite_tables
If you don't have SQLite available, Bacula provides it as a package. See the Bacula database URL above for more information. If I had MySQL installed, I could have done this instead:
# cd /usr/ports/sysutils/bacula/work/bacula-1.32c/src/cats # ./grant_mysql_privileges # ./create_mysql_database # ./make_mysql_tables
If you have a password set for the MySQL root account, add
-p to the above commands and you will be prompted for the password.
You now have a working database suitable for use by Bacula. This database can be cleared out from time to time, especially as you reuse old tapes. Please refer to the Catalog Maintenance and Automatic Volume Recycling documentation. You can recycle volumes manually or automatically.
Testing Your Tape Drive
If you are not using a tape drive, you can skip this section.
Some tape drives are not standard. They work with their proprietary software and can be temperamental when used with other software. Each drive model can have its own little quirks that need to be catered for. Fortunately, Bacula comes with a handy little utility for testing your drive.
I used btape
to test my tape drive. I will be using a FreeBSD system. Please adjust the
paths for your operating system. The tape drive I use is
/dev/sa1, but I will actually test the non-rewinding raw device
The output from this command is long so I have cut out the non-essential parts. The full text is available.
# /usr/local/sbin/btape -c /usr/local/etc/bacula-sd.conf /dev/nrsa1 Tape block granularity is 1024 bytes. btape: butil.c:149 Using device: /dev/nrsa1 for writing. *test === Append files test === This test is essential to Bacula. I'm going to write one record in file 0, two records in file 1, and three records in file 2 btape: btape.c:380 Rewound /dev/nrsa1 btape: btape.c:845 Wrote one record of 64412 bytes. btape: btape.c:847 Wrote block to device. [snip] The above Bacula scan should have output identical to what follows. Please double check it ... === Sample correct output === [snip] === End Append files test === *
The good news is no problems. The bad news, if you can call it that, is btape has some suggestions for improvement. I altered my storage device to include the following:
Hardware End of Medium = No BSF at EOM = yes
I also ran
btape again to make sure it was still OK. It was. I
suggest you also run this test.
Running as Non-root
It is a good idea to run daemons with the lowest possible privileges. In other words, if you can, don't run applications as root that do not have to be root. The Storage Daemon and the Director Daemon do not need to be root. The File Daemon needs to be root in order to access all files on your system. In order to run as non-root, you need to create a user and a group. Choosing
bacula as both the user name and the group name sounds like a good idea to me.
The FreeBSD port creates this user and group for you (actually, as I write this, the port doesn't do that, but it soon will). Here is what those entries looked like on my FreeBSD laptop:
vipw to create this entry. I selected User and Group IDs of 1002, as they were unused on my system.
I also created a group in
The bacula user (as opposed to the Bacula daemon) will have a home directory of
/var/db/bacula, which is the default location for the Bacula database.
Now that you have both a bacula user and a bacula group, you can secure the bacula home directory by issuing this command:
chown -R bacula:bacula /var/db/bacula/
This ensures that only the bacula user can access this directory. It also means that if we run the Director and the Storage daemon as bacula, those daemons also have restricted access. This would not be the case if they were running as root.
It is important to note that the storage daemon actually needs to be in the operator group for normal access to devices such as tape drives. (At least on a FreeBSD system; that's how things are set up by default.) Such devices are normally owned by the root user and the operator group. It is easier and less error prone to make Bacula a member of that group than it is to play around with system permissions.
Starting the Bacula Daemons
To start the bacula daemons on a FreeBSD system, issue the following command:
To confirm they are all running:
$ ps auwx | grep bacula root 63416 0.0 0.3 2040 1172 ?? Ss 4:09PM 0:00.01 /usr/local/sbin/bacula-sd -v -c /usr/local/etc/bacula-sd.conf root 63418 0.0 0.3 1856 1036 ?? Ss 4:09PM 0:00.00 /usr/local/sbin/bacula-fd -v -c /usr/local/etc/bacula-fd.conf root 63422 0.0 0.4 2360 1440 ?? Ss 4:09PM 0:00.00 /usr/local/sbin/bacula-dir -v -c /usr/local/etc/bacula-dir.conf
Starting the Bacula Console
Bacula's console is your main interface to the Director daemon. Here you can run jobs and backup or restore manually. You can query system status, examine the Catalog contents, as well as label, mount, and unmount tapes. The Console communicates with the Bacula Director via the network, so the two programs do not need to reside on the same machine.
There are two consoles available. One runs from the command line, the other is a GNOME GUI. I will concentrate on the command line.
To start the console, I use this command:
$ /usr/local/sbin/console -c /usr/local/etc/console.conf Connecting to Director laptop:9101 1000 OK: laptop-dir Version: 1.32c (30 Oct 2003) *
You can obtain a list of the commands available with the
command. One of the first commands I issue is
which can be abbreviated to
au on. Autodisplay will automatically
display any messages from Bacula without you having to enter the
status all command not only displays the status of each system component, it is also a quick and easy way to verify that all components are up and running and that all is well.
*status all Using default Catalog name=MyCatalog DB=bacula laptop-dir Version: 1.32c (30 Oct 2003) i386-portbld-freebsd4.8 freebsd 4.8-STABLE Daemon started 02-Nov-2003 12:42, 1 Job run. Last Job *Console*.2003-11-02_13.12.18 finished at 02-Nov-2003 13:12 Files=0 Bytes=0 Termination Status=Error Console connected at 02-Nov-2003 13:12 No jobs are running. Scheduled Jobs: Level Type Scheduled Name Volume =============================================================================== Incremental Backup 03-Nov-2003 01:05 Client1 *unknown* Full Backup 03-Nov-2003 01:10 BackupCatalog *unknown* ==== Connecting to Storage daemon File at laptop.example.org:9103 laptop-sd Version: 1.32c (30 Oct 2003) i386-portbld-freebsd4.8 freebsd 4.8-STABLE Daemon started 02-Nov-2003 12:42, 0 Jobs run. Device /tmp is not open. No jobs running. ==== Connecting to Client laptop-fd at laptop.example.org:9102 Failed to connect to Client laptop-fd. ==== 02-Nov-2003 13:13 laptop-dir: *Console*.2003-11-02_13.12.48 Fatal error: Director and File daemon passwords or names not the same. *
As you can see, there is a problem with my File Daemon. That is my fault. I was running a client-only installation of Bacula on my laptop, but for this article, I installed the full server. That meant
/usr/local/etc/bacula-fd.conf contained the wrong name for the Director. It was referring to another Director. Once I changed it to the correct value (
laptop-fd) and restarted
bacula-fd, all was well. I verified the status using this command:
*status client=laptop-fd Connecting to Client laptop-fd at laptop.example.org:9102 laptop-fd Version: 1.32c (30 Oct 2003) i386-portbld-freebsd4.8 freebsd 4.8-STABLE Daemon started 02-Nov-2003 16:20, 0 Jobs run. Director connected at: 02-Nov-2003 16:20 No jobs running. ==== *
We have verified that each daemon is up and running, and that the Director can contain both the Storage and the File daemon. Things are looking good!