Presumably the configuration files (in their most recent form) are already stored on the tapes. An automated way of finding and pulling them would be useful, perhaps bundled with a tape scan to find the most recent catalog?
Clint On Mon, 5 Dec 2011, Pablo Marques wrote: > Thanks you Jesse for the feedback. > > Regarding the disaster recovery, I have a suggestion for the bacula team: > > Why not make the director write the bacula config files and any relevant bsr > files at the beginning of each tape? > The space wasted on the tape to save these file would be very small. > > These files could be easily recovered with btape on a total disaster recovery > situation when you only have tapes (and hopefully a tape drive) and nothing > else. > > How difficult could it be to modify bacula to make the above automated when a > tape is labeled and/or a recycled tape is written on again for example? > > Pablo > > > ----- Original Message ----- > From: "Jesse Molina" <je...@opendreams.net> > To: bacula-users@lists.sourceforge.net > Sent: Sunday, December 4, 2011 9:39:06 PM > Subject: [Bacula-users] Noob user impressions and why I chose not to use > Bacula > > > 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 shit! 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 = je...@opendreams.net > # Page = page-je...@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@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users > > ------------------------------------------------------------------------------ > 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@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users > ------------------------------------------------------------------------------ Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
