[Bacula-users] Constructive criticism of current bacula systems

[Eric Warnke]

We are currently evaluating OSS backup solutions for our research file storage needs and are running into several issues with bacula.  We are current backing up 700GiB of online storage, and we have physical storage for over 10TiB.  We have an autochanger with 23 slots and LTO3 tapes ( 400/800 ), so we have plenty of capacity.  I am not a noob or a moron, I have spent the past several weeks tweaking bacula to meet our local requirements with mixed success.  I have been doing Linux systems administration and programming professionally for over a decade and have done disk to disk as well as disk to tape solutions so I have a firm grasp of what is achievable.

This is an evaluation of 1.38.6.

The good.

1) Autochanger worked basicly out of the box
2) Basic backup schedule worked basicly out of the box.
3) Flexibility

The Bad.

1) RPM's seem horribly broken.  This includes, but is not limited to...

( sqlite version ).  All of the paths in /etc/bacula/*sqlite* are screwed up and need to be changed by hand and rerun.  Even when you re-run by hand you still have problems since the permissions on the new database are probably wrong and will need correcting, again by hand.

Comments about the RPM in general.  Stock config files are horribly broken if RPM is built on another host.

2) SQLite has undocumented limitations that make it inappropriate for many site that might be interested in this product.  First off, if there is any contention for the database ( ie, looking at the state of the database, or running updates using sqlquery can cause running jobs to fail ); because of this I just lost a 7 hour backup.  Secondly, there is a 2gb limit on sqlite databases that will cause many MANY headaches for any site that installs this product and then later runs into this problem.

3) Config files are needlessly over complex.  It has taken weeks to fine tune the config files in order to achieve a stated goal for our in-house needs that is not overly complex ( 90 days of guaranteed backups ).  Almost every time a complex change was made to the config required stopping everything, wiping the database, wiping labels and restarting.  This does not give me the warm fuzzies about how this system will fare under a production load.  Another problem with configs is that something as simple as leaving the level off of a Schedule run = line will cause the director to silently crash.

4) The way that incremental and differentials are structured does not allow for good differential pooling since incremental can be based on differentials.  Because of this you can't recycle your differentials before you re-run a full backup.  If incremental were only based on fulls or incremental, you can recycle your differentials on a faster cycle to reduce tape space for in exchange for longer restore times for older files.

5) Does not back up all files.  As noted in the documentation, bacula uses mtime for incremental leading to possibility of missing files in an incremental and differential backup because of movement, incorrect touch, system date set incorrectly, or possibly other issue.  This alone would be a show stopper if the rest of the system was not as refined as it is.  This is noted in the docs, but I did not discover it until after we started evaluating it.

6) Does not track deletions between full backups.  Restoration will uncover deleted files.  Over a long period of time this could lead to restorations that exceed the space on the partition that is being restored especially for sites that have long retention periods and heavy tunover.  The major problem is that there is probably no way to stort out those files that belong and those that do not!


This list does not mean that we will not end up using bacula since this list looks better than the alternatives, but is a list of items that give me pause to implement this system on a full time production status.  At a minimum these items should be noted in the documentation ( some already are ).  This list is also out there for others who might be evaluating this project for their use as well.

Cheers,
Eric Warnke
Systems Administrator
Research IT, SUNY Albany