Hi
Recently I was looking for new backup app for my small network. Here's
my story and why I decided that Bacula was not a good choice for me.
I am not a long time user, so opinions and views may not be shared by
others, but they are true none the less. You can only be a noob once
and I hope this criticism can he constructive and helpful.
I am not looking for any response from any users. You don't need to
defend Bacula from some noob with a questionable opinion.
Note that some of my notes below were jotted down in haste during
testing Bacula and some of my comments might be rather harsh or vulgar.
I'm not trying to troll or bash, and I hope these comments can be used
to improve Bacula, and maybe I will get to use it again some day and it
will be a better product.
I tried to throw all of these notes into a coherent whole, but I'm sure
some of it will come off as being out of order to not making any sense.
--
I've got two Linux servers, a Mac, Windows, and Linux desktop, and a
number of remote hosts. The main host fileset is about 750GB, and all
of the other various clients roll into about 600GB. I have a single DLT
S4 (800GB native) drive direct attached to a primary server host via
Ultra320 bus.
I am an experienced sysadmin and I've previously been the primary
maintainer of one TSM system and assisted with multiple others.
In the end, I just wrote my own scripts using ssh, rsync and tar. It's
"good enough".
In summary, I could say I was attracted to the idea that Bacula used
it's own data archive format and had a database for it's catalog, but
was really turned off when I figured out that configuration was not also
stored in a database, and how complicated actual restoration was.
I find the modular nature of Bacula's components very attractive, as it
allows for scaling across multiple hosts for various functions.
However, I don't understand the historical need to call the File Daemon
anything other than what it is and what everyone seems to want call it:
a Client. Rename it to the Client Daemon and get over it.
While I appreciate the SQL DB used for historical data (Catalog), I find
that primary configuration and some temporary data is scattered across
various files. It makes things complicated and difficult. It will
always be necessary to have some small configuration to point towards
the other daemons and provide passwords, but using config files just
makes management difficult. SQL is not hard and Bacula isn't a simple
program. I would refer to Nagios vs Icinga as a good example of
complicated text config systems gone bad. When you have so much
re-usable configuration data and complicated relationships, that's what
DBs were made for. Add a separate config DB and then all configuration
should be done via bconsole, and a webUI. Configuration could be dumped
and loaded via bconsole or maybe an import/export commands alla
Juniper/Cisco.
As for user interfaces, bconsole is good and I never really bothered
with anything else. The one huge complaint I have is that eject and
other basic loader controls are absent and should be added. I got
really tired of having to umount, ctrl-z, and then call mt just to eject
my tape during testing. I realize that this is more complicated for
autoloader libs, but allow the user to configure a backend-script for
the command and there you go. This can be done.
Documentation sucks. It's just not a priority for this project and it
shows. Tons of typos, the formatting and layout is horrible, and for
the English language I get the impression there are a lot of
translation-isms. It was like reading a paper written by five different
college students where each one wrote a different portion with a
different writing style.
In a number of cases, two sentences having the same or very similar
meaning will be in the same paragraph. Effectively saying the same
thing twice or more.
For example:
"Bacula can automatically label Volumes if instructed to do so, but this
feature is not yet fully implemented. "
Really, WTF? If it's not implemented, don't document it.
http://www.bacula.org/5.0.x-manuals/en/main/main/Messages_Resource.html
For "console = all, !skipped, !saved" in a Messages configuration
object, there is no documented explanation for the "saved" message-type.
"notsaved" is documented, but "saved" is not.
I would call the "Messages Resource" documentation page a readability
disaster. I would say the primary problem is lack of appropriate
indentation. In some cases, it looks like indentation was intended, but
it's not there. PDF-to-HTML disaster?
Documentation constantly and annoyingly warns you about nonsense that
you don't need to be warned about, provides guidance that does not need
to be given, and repeats the same advice multiple times in different
contexts for no apparent reason. For example, the documentation on
restores says, "Please examine each of the items very carefully to make
sure that they are correct. " and then two paragraphs later, "Returning
to the above example, you should verify that the Client name is correct
before running the Job. " No crap! Entire paragraphs of
grandma-flavored, "don't forget your coat", nagging could be eliminated.
I found documentation regarding the Bootstrap File to be very lacking.
What is it? Is it important? Usage examples? There just isn't all
that much on the subject, which brings us to...
Recovery seems to be an after-thought for this product. Just compare
the amount of what is written to getting backups done versus recovery
operations. Backups are pointless if you can't recover.
This is where Bacula really fell apart for me and I gave up. I realized
how difficult it was going to be for me to recover from a disaster using
Bacula versus using tar and that was it, I knew this wasn't worth it.
Reading about all the cases where Bacula could not back up or restore
ACLs just made me question the usefulness of Bacula's backups.
This is a joke:
"
Bare Metal Recovery assumes that you have the following items for your
system:
...
A second system running the Bacula Director, the Catalog, and the
Storage daemon. (this is not an absolute requirement, but how to get
around it is not yet documented here)
"
The problem is that nowhere does Bacula assume loss of everything except
the backup media(tapes). True disaster recovery assumes an actual
disaster, which Bacula seems to always assumes never happens. A user
needs to be able to restore, with as much ease as possible, from nothing
other than one or two backup tapes. I get the impression that recovery
in general was an afterthought in Bacula's design, but a true "disaster"
where everything is lost just isn't in any recovery scenario for Bacula.
You might argue that Bacula is just a framework that needs to be
customized for each organization, but there should be some examples or
discussion on the subject and there just isn't anything.
I'm thinking of the way TSM does it with it's database tape. That would
be fine, but Bacula has it's config files (on different hosts), the
catalog and bootstap files, which would be extremely difficult to
restore if backed up with Bacula. Basically, you need a Bacula tape,
and then a tar tape just for your config+catalog+etc. You can't easily
restore a Bacula installation without that same configured installation
already being in place.
For example, see "Steps to Take Before Disaster Strikes" in the recovery
manual:
"Ensure that you always have a valid bootstrap file for your backup and
that it is saved to an alternate machine."
"If possible copy your catalog nightly to an alternate machine."
"Make a copy of your Bacula .conf files, particularly your
bacula-dir.conf, and your bacula-sd.conf files, because if your server
goes down, these files will be needed to get it back up and running, and
they can be difficult to rebuild from memory. "
Bacula just isn't designed for real disasters, where the only thing that
survived were the off-site tapes.
There needs to be a simple command which will backup and restore
(directly from volume) the catalog DB, the entire configuration
(including clients), state information (.state files), and then maybe
some additional arbitrary data (system info, local documentation, etc).
Believe it or not, I find TSM's recovery procedure easier than what
Bacula comes with.
Finally, here's some other notes and questions I had come up with during
my installation and tests:
How is it possible to commit the configuration of a new client and new
job without restarting the director and interrupting a running job? I
get the impression that this is not possible. This would be a huge
problem for large environments!
I found the director to react very poorly to issues with the storage
daemon. I often had to restart the director if the storage daemon was
killed/crashed or other strange things happened. The director needs to
be more resilient to component issues.
The "setdebug" command. Because just "debug" is too few letters or
something.
"sqlquery": Wow, what a powerful and helpful command, built right into
the bconsole! Awesome!
There is no way to remove a volume's label from bconsole. This sucks
and wastes time for testing. Please just add it. Maybe check to make
sure a "delete volume" has been done first.
Director start and restart messages are not logged to the log file.
aclsupport=no is default? WTF. Bacula won't save Unix ACL info by default?
The Bacula Tray Monitor is worthless. It's a horrible waste of bits.
Just log to a file and tail -f the logfile instead.
References to "cat /proc/scsi/scsi" in documentation are invalid for
newer kernels. Needs updating.
--
"
Bootstrap File
The bootstrap file is an ASCII file containing a compact form of
commands that allow Bacula or the stand-alone file extraction utility
(bextract) to restore the contents of one or more Volumes, for example,
the current state of a system just backed up. With a bootstrap file,
Bacula can restore your system without a Catalog. You can create a
bootstrap file from a Catalog to extract any file or files you wish.
...
If you have used the WriteBootstrap record in your job or some other
means to save a valid bootstrap file, you will be able to use it to
extract the necessary files (without using the catalog or manually
searching for the files to restore).
...
"
But then...
"The bextract program does not restore access control lists (ACLs) to
Unix machines. "
How do you reconcile this? Both can not be true. Imagine a Linux
system being restore without file permissions.
--
Bacula's default block size is 65KB is getting rather small. My
five-year-old DLT S4 drive can take a 16MB block. At least this can be
configured easily.
--
# Jesse Molina
# Mail = jesse < at > opendreams.net
# Page = page-jesse < at > opendreams.net
# Cell = 1.602.323.7608
# Web = http://www.opendreams.net/jesse/
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Bacula-users mailing list
Bacula-users < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
.... I was expecting to see a good flame-throwing thread
