Feb 022011
 

Introduction

Backups are a subject I return to semi-frequently with a passion to never be in an “oh shit” scenario.  Last time I built my backup system, bacula with a postgresql DB backend, I determined that I would move to a common database backup script for all of my databases.  Holland fit this bill perfectly with support for postgres, sqlite and mysql.  This allows one command to backup all of my databases on all of my servers and subsequently creates a much simpler bacula configuration (the database job is defined the same as the catalog job).

The Solution

The problem I had when configuring holland to backup postgresql is that there was no example configuration file.  It wasn’t hard to craft a working default postgres configuration and the following is what I came up with (/etc/holland/backupsets/default.conf:

[holland:backup]
plugin = pgdump
backups-to-keep = 1
auto-purge-failures = yes
purge-policy = after-backup
estimated-size-factor = 1.0

[pgdump]
role = postgres

[pgauth]
username = postgres

Conclusion

Setting up holland to backup databases is incredibly easy and flexible.  By having a common backup solution for all databases other configurations become easier and processes can be streamlined.

Jun 272010
 

Introduction

Backups, a subject that is always talked about but rarely put into practice. If you do happen to have a backup solution, excellent, you probably sleep better than our comrades without a recovery plan. I’ve been using bacula for my backup solution for over a year now and one thing I’ve never had enough experience with has been upgrading bacula. The upgrade process can be pretty hairy depending your distribution, level of investment, etc.

Bacula Updates

Recently bacula-5.0.2-r1 was marked as stable for the Gentoo distribution. Upon finishing the emerge (laugh if you like at my compilation of all packages), I attempted the restart of all bacula services to bring the new version live:

/etc/init.d/bacula-sd restart
/etc/init.d/bacula-fd restart
/etc/init.d/bacula-dir restart

All went well until I did the restart on the director (bacula-dir). At that point things took a nasty turn for the worse. The director didn’t want to start and there were no messages on the screen indicating why this might be the case.

Long story short: the database needed some schema changes to be applied before the director could start up and get running again. In order to determine this I needed to run: `bacula -u root -g bacula -c /etc/bacula/bacula-dir.conf -fvm`. Once I ran this I got some meaningful output that told me I needed to update the database a couple of versions. It’s important to know which versions you are dealing with as you have to run each update to the database individually.

First, a dump of all databases that are relevant is a good idea: `mysqldump -A -p > backup.sql`. Then, we can move onto updating the databases knowing full well that if something goes awry we simply import our backup and revert bacula to the old version.

The database update scripts were located in `/usr/libexec/bacula/updatedb/` and when run in the correct order will get you back up and running in short order. When all is said and done utter the `/etc/init.d/bacula-dir` and your installation should whir to life once again.

Conclusion

When updating bacula don’t forget the catalog database may have changes that require it to be updated using the various bacula updatedb scripts. Backups should commence at their regularly scheduled time.

© 2011 Alunduil's Hosting Suffusion theme by Sayontan Sinha