Next: Installing and Configuring SQLite Up: Main Reference Previous: Installing and Configuring MySQL Contents Index
If you have installed PostgreSQL from a package (.deb, .rpm, ...) or already installed it from source, please skip to the next section.
If you are building PostgreSQL from source, please be sure to add the --enable-thread-safety option when doing the ./configure for PostgreSQL.
If you use the ./configure --with-postgresql=PostgreSQL-Directory statement for configuring Bacula, you will need PostgreSQL version 7.4 or later installed. NOTE! PostgreSQL versions earlier than 7.4 do not work with Bacula. If PostgreSQL is installed in the standard system location, you need only enter --with-postgresql since the configure program will search all the standard locations. If you install PostgreSQL in your home directory or some other non-standard directory, you will need to provide the full path with the --with-postgresql option.
Installing and configuring PostgreSQL is not difficult but can be confusing the first time. If you prefer, you may want to use a package provided by your chosen operating system. Binary packages are available on most PostgreSQL mirrors.
If you prefer to install from source, we recommend following the instructions found in the PostgreSQL documentation.
If you are using FreeBSD, this FreeBSD Diary article will be useful. Even if you are not using FreeBSD, the article will contain useful configuration and setup information.
If you configure the Batch Insert code in Bacula (attribute inserts are 10 times faster), you must be using a PostgreSQL that was built with the --enable-thread-safety option, otherwise you will get data corruption. Most major Linux distros have thread safety turned on, but it is better to check. One way is to see if the PostgreSQL library that Bacula will be linked against references pthreads. This can be done with a command such as:
nm /usr/lib/libpq.a | grep pthread_mutex_lock
The above command should print a line that looks like:
U pthread_mutex_lock
if does, then everything is OK. If it prints nothing, do not enable batch inserts when building Bacula.
After installing PostgreSQL, you should return to completing the installation of Bacula. Later, after Bacula is installed, come back to this chapter to complete the installation. Please note, the installation files used in the second phase of the PostgreSQL installation are created during the Bacula Installation. You must still come back to complete the second phase of the PostgreSQL installation even if you installed binaries (e.g. rpm, deb, ...).
At this point, you should have built and installed PostgreSQL, or already have a running PostgreSQL, and you should have configured, built and installed Bacula. If not, please complete these items before proceeding.
Please note that the ./configure used to build Bacula will need to include --with-postgresql=PostgreSQL-directory, where PostgreSQL-directory is the directory name that you specified on the ./configure command for configuring PostgreSQL (if you didn't specify a directory or PostgreSQL is installed in a default location, you do not need to specify the directory). This is needed so that Bacula can find the necessary include headers and library files for interfacing to PostgreSQL.
An important thing to note here is that Bacula makes two connections to the PostgreSQL server for each backup job that is currently running. If you are intending to run a large number of concurrent jobs, check the value of max_connections in your PostgreSQL configuration file to ensure that it is larger than the setting Maximum Concurrent Jobs in your director configuration. Setting this too low will result in some backup jobs failing to run correctly!
Bacula will install scripts for manipulating the database (create, delete, make tables etc) into the main installation directory. These files will be of the form *_bacula_* (e.g. create_bacula_database). These files are also available in the bacula-src/src/cats directory after running ./configure. If you inspect create_bacula_database, you will see that it calls create_postgresql_database. The *_bacula_* files are provided for convenience. It doesn't matter what database you have chosen; create_bacula_database will always create your database.
Now you will create the Bacula PostgreSQL database and the tables that Bacula uses. These instructions assume that you already have PostgreSQL running. You will need to perform these steps as a user that is able to create new databases. This can be the PostgreSQL user (on most systems, this is the pgsql user).
This directory contains the Bacula catalog interface routines.
su
(enter root password)
su pgsql (or postgres)
createuser bacula
Shall the new user be allowed to create databases? (y/n) y
Shall the new user be allowed to create more new users? (y/n) (choose
what you want)
exit
In newer versions of PostgreSQL, it will not automatically ask if the user bacula should be able to create databases or create new users. To do so you may need to use the -s option on the createuser command. Example:
createuser -s bacula
Normally the bacula user must be able to create new databases, if you use the script in the next item, or you will have to create one for it, but it does not need to create new users.
This script creates the PostgreSQL bacula database. Before running this command, you should carefully think about what encoding sequence you want for the text fields (paths, files, ...). We strongly recommend that you use the default value of SQL_ASCII that is in the create_bacula_database script. Please be warned that if you change this value, your backups may fail. After running the script, you can check with the command:
psql -l
and the column marked Encoding should be SQL_ASCII for all your Bacula databases (normally bacula).
This script creates the PostgreSQL tables used by Bacula.
This script creates the database user bacula with restricted access rights. You may want to modify it to suit your situation. Please note that this database is not password protected.
Each of the three scripts (create_bacula_database, make_bacula_tables, and grant_bacula_privileges) allows the addition of a command line argument. This can be useful for specifying the user name. For example, you might need to add -h hostname to the command line to specify a remote database server.
To take a closer look at the access privileges that you have setup with the above, you can do:
PostgreSQL-directory/bin/psql --command \\dp bacula
Also, I had an authorization problem with the password. In the end, I had to modify my pg_hba.conf file (in /var/lib/pgsql/data on my machine in /var/lib/postgresql/8.x on others, and in /etc/postgres/8.x/main on still others - what a mess!) from:
local all all ident sameuser to local all all trust
This solved the problem for me, but it is not always a good thing to do from a security standpoint. However, it allowed me to run my regression scripts without having a password.
A more secure way to perform database authentication is with md5 password hashes. Begin by editing the pg_hba.conf file, and above the existing ``local'' and ``host'' lines, add the line:
local bacula bacula md5
then restart the Postgres database server (frequently, this can be done using "/etc/init.d/postgresql restart" or "service postgresql restart") to put this new authentication rule into effect.
Next, become the Postgres administrator, postgres, either by logging on as the postgres user, or by using su to become root and then using su - postgres or su - pgsql to become postgres. Add a password to the bacula database for the bacula user using:
\$ psql bacula bacula=# alter user bacula with password 'secret'; ALTER USER bacula=# \\q
You'll have to add this password to two locations in the bacula-dir.conf file: once to the Catalog resource and once to the RunBeforeJob entry in the BackupCatalog Job resource. With the password in place, these two lines should look something like:
dbname = bacula; user = bacula; password = "secret"
... and ...
# WARNING!!! Passing the password via the command line is insecure.
# see comments in make_catalog_backup for details.
RunBeforeJob = "/etc/make_catalog_backup bacula bacula secret"
Naturally, you should choose your own significantly more random password, and ensure that the bacula-dir.conf file containing this password is readable only by the root.
Even with the files containing the database password properly restricted, there is still a security problem with this approach: on some platforms, the environment variable that is used to supply the password to Postgres is available to all users of the local system. To eliminate this problem, the Postgres team have deprecated the use of the environment variable password-passing mechanism and recommend the use of a .pgpass file instead. To use this mechanism, create a file named .pgpass containing the single line:
localhost:5432:bacula:bacula:secret
This file should be copied into the home directory of all accounts that will need to gain access to the database: typically, root, bacula, and any users who will make use of any of the console programs. The files must then have the owner and group set to match the user (so root:root for the copy in root, and so on), and the mode set to 600, limiting access to the owner of the file.
After you have done some initial testing with Bacula, you will probably want to re-initialize the catalog database and throw away all the test Jobs that you ran. To do so, you can do the following:
cd <install-directory> ./drop_bacula_tables ./make_bacula_tables ./grant_bacula_privileges
Please note that all information in the database will be lost and you will be starting from scratch. If you have written on any Volumes, you must write an end of file mark on the volume so that Bacula can reuse it. Do so with:
(stop Bacula or unmount the drive) mt -f /dev/nst0 rewind mt -f /dev/nst0 weof
Where you should replace /dev/nst0 with the appropriate tape drive device name for your machine.
postgresql postgresql-devel postgresql-server postgresql-libs
and the following for debs:
postgresql postgresql-common postgresql-client postgresql-client-common libpq5 libpq-dev
These will be similar with most other package managers too. After installing from rpms, you will still need to run the scripts that set up the database and create the tables as described above.
The conversion procedure presented here was worked out by Norm Dressler ndressler at dinmar dot com
This process was tested using the following software versions:
WARNING: Always as a precaution, take a complete backup of your databases before proceeding with this process!
mysqldump -t -n -c --compatible=postgresql --skip-quote-names --skip-opt \
--disable-keys --lock-tables -u bacula -ppassword bacula \
| grep -v "INSERT INTO Status" \
| sed -e 's/0000-00-00 00:00:00/1970-01-01 00:00:00/g' \
| sed -e 's/\\0//' > bacula-backup.sql
local all all trust
host all all 127.0.0.1 255.255.255.255 trust
NOTE: you should reload (or restart) your postgres server if you made changes
./create_postgresql_database
./make_postgresql_tables
./grant_postgresql_privileges
psql -Ubacula bacula
You should not get any errors.
psql -Ubacula bacula <bacula-backup.dmp>
psql -Ubacula bacula
SELECT SETVAL('basefiles_baseid_seq', (SELECT MAX(baseid) FROM basefiles));
SELECT SETVAL('client_clientid_seq', (SELECT MAX(clientid) FROM client));
SELECT SETVAL('file_fileid_seq', (SELECT MAX(fileid) FROM file));
SELECT SETVAL('filename_filenameid_seq', (SELECT MAX(filenameid) FROM filename));
SELECT SETVAL('fileset_filesetid_seq', (SELECT MAX(filesetid) FROM fileset));
SELECT SETVAL('job_jobid_seq', (SELECT MAX(jobid) FROM job));
SELECT SETVAL('jobmedia_jobmediaid_seq', (SELECT MAX(jobmediaid) FROM jobmedia));
SELECT SETVAL('media_mediaid_seq', (SELECT MAX(mediaid) FROM media));
SELECT SETVAL('path_pathid_seq', (SELECT MAX(pathid) FROM path));
SELECT SETVAL('basefiles_baseid_seq', (SELECT MAX(baseid) FROM basefiles));
SELECT SETVAL('client_clientid_seq', (SELECT MAX(clientid) FROM client));
SELECT SETVAL('file_fileid_seq', (SELECT MAX(fileid) FROM file));
SELECT SETVAL('filename_filenameid_seq', (SELECT MAX(filenameid) FROM filename));
SELECT SETVAL('fileset_filesetid_seq', (SELECT MAX(filesetid) FROM fileset));
SELECT SETVAL('job_jobid_seq', (SELECT MAX(jobid) FROM job));
SELECT SETVAL('jobmedia_jobmediaid_seq', (SELECT MAX(jobmediaid) FROM jobmedia));
SELECT SETVAL('media_mediaid_seq', (SELECT MAX(mediaid) FROM media));
SELECT SETVAL('path_pathid_seq', (SELECT MAX(pathid) FROM path));
SELECT SETVAL('pool_poolid_seq', (SELECT MAX(poolid) FROM pool));
SELECT SETVAL('device_deviceid_seq', (SELECT MAX(deviceid) FROM device));
SELECT SETVAL('location_locationid_seq', (SELECT MAX(locationid) FROM location));
SELECT SETVAL('locationlog_loclogid_seq', (SELECT MAX(loclogid) FROM locationlog));
SELECT SETVAL('log_logid_seq', (SELECT MAX(logid) FROM log));
SELECT SETVAL('mediatype_mediatypeid_seq', (SELECT MAX(mediatypeid) FROM mediatype));
SELECT SETVAL('storage_storageid_seq', (SELECT MAX(storageid) FROM storage));
If you despool attributes for many jobs at the same time, you can tune the sequence object for the FileId field.
psql -Ubacula bacula ALTER SEQUENCE file_fileid_seq CACHE 1000;