Re: [Bacula-users] Noob user impressions and why I chose not to use Bacula
On 12/09/11 15:18, Tilman Schmidt wrote: > Am 06.12.2011 10:07, schrieb Phil Stracchino: >> On 12/06/11 03:10, Marcello Romani wrote: >>> The closest thing to a custom "eject tape" builtin command in bconsole I >>> could came up with is this: > [...] >> >> You know, personally I just set "OfflineOnUnmount = yes". > > IIRC that option turned out to be more trouble than it was worth. > In particular, labelling a new tape didn't work anymore with this > option set, because the tape would be ejected in the middle of > the operation, followed by a complaint about the missing tape. > Has that changed? I don't believe I have ever had that happen. I can verify as of just last night that I can label a new tape on demand in the middle of a backup on an LTO4 drive, from BAT, without any unexpected ejects, and 5.2.2 automatically mounted the tape after labelling. -- Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355 ala...@caerllewys.net ala...@metrocast.net p...@co.ordinate.org Renaissance Man, Unix ronin, Perl hacker, SQL wrangler, Free Stater It's not the years, it's the mileage. -- 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
Re: [Bacula-users] Noob user impressions and why I chose not to use Bacula
Am 06.12.2011 10:07, schrieb Phil Stracchino: > On 12/06/11 03:10, Marcello Romani wrote: >> The closest thing to a custom "eject tape" builtin command in bconsole I >> could came up with is this: [...] > > You know, personally I just set "OfflineOnUnmount = yes". IIRC that option turned out to be more trouble than it was worth. In particular, labelling a new tape didn't work anymore with this option set, because the tape would be ejected in the middle of the operation, followed by a complaint about the missing tape. Has that changed? -- Tilman Schmidt Phoenix Software GmbH Bonn, Germany -- 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
Re: [Bacula-users] Noob user impressions and why I chose not to use Bacula
Il 06/12/2011 10:07, Phil Stracchino ha scritto: > On 12/06/11 03:10, Marcello Romani wrote: >> Il 05/12/2011 03:39, Jesse Molina ha scritto: >> >> [snip food for thought] >> >> The closest thing to a custom "eject tape" builtin command in bconsole I >> could came up with is this: >> >> # admin job to manually eject tape from within bconsole >> Job { >> Name = "TapeEject" >> Type = Admin >> FileSet = "LinuxDefaultSet" >> Client = serverlinux-fd >> Storage = Tape >> Pool = Tape >> Messages = Standard >> RunBeforeJob = "echo 'umount storage=Tape' | bconsole" >> RunAfterJob = "mt-st -f /dev/nst0 offl" >> } >> >> This works on my setup, where I have a single tape drive (LTO-1, for the >> record). No autochanger. > > > You know, personally I just set "OfflineOnUnmount = yes". > > > (The Tape storage was already unmounted when I tested the job.) It seems the proper way to unmount & eject with a single command is to use offline on unmount = yes. Thanks. -- Marcello Romani -- 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
Re: [Bacula-users] Noob user impressions and why I chose not to use Bacula
On 12/06/11 14:03, Josh Fisher wrote: > Rather than change the formatting of a volume, why not use a dedicated > volume? The first problem to overcome in a true disaster recovery > situation, ie. a total loss of all hardware, is to get a Dir and SD up > and running. Clients can then be restored with a much simpler, generic > USB boot device. Booting the new Director from a disaster recovery USB > stick is much more complicated, since we must somehow get the database > and config files restored. If there was a reserved volume label > dedicated to having the most current config files and catalog, then a > disaster recovery boot device for the Dir should not be necessary. All > that would be needed is a minimal OS and fresh install of Bacula. I like this idea. > I am not a fan of relying on the availability of identical replacement > hardware. In a disaster recovery, it is not unlikely that one would be > forced to utilize whatever hardware is immediately available. Since this > can affect number of disks, partitioning, etc., I prefer to install a > minimal OS, along with Bacula and a SQL database server, and then > restore the Dir. Additionally, you may be in the position of "As long as we're rebuilding the box anyway, let's make a few hardware changes, we'd get better performance if we [fitb...]" -- Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355 ala...@caerllewys.net ala...@metrocast.net p...@co.ordinate.org Renaissance Man, Unix ronin, Perl hacker, SQL wrangler, Free Stater It's not the years, it's the mileage. -- 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
Re: [Bacula-users] Noob user impressions and why I chose not to use Bacula
On 12/5/2011 1:48 PM, Phil Stracchino wrote: > On 12/05/11 10:58, 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. > Well, the first problem here is that the Director would have to know how > much space it was going to need for BSR files. Of course, it could > pre-allocate a fixed-size block of, say, 1MB for BSR files. > > The second problem, it seems to me, is that this would break > compatibility with all older Bacula volumes and installations. Rather than change the formatting of a volume, why not use a dedicated volume? The first problem to overcome in a true disaster recovery situation, ie. a total loss of all hardware, is to get a Dir and SD up and running. Clients can then be restored with a much simpler, generic USB boot device. Booting the new Director from a disaster recovery USB stick is much more complicated, since we must somehow get the database and config files restored. If there was a reserved volume label dedicated to having the most current config files and catalog, then a disaster recovery boot device for the Dir should not be necessary. All that would be needed is a minimal OS and fresh install of Bacula. There would be two special jobs. One would backup config files and catalog SQL file into a new volume. The data could be written to any new/empty volume in the normal way, but at completion, the special job would relabel the volume to have the reserved volume label. The second special job would be to restore config and catalog from the reserved volume. The first special job would be run daily, or at whatever frequency the catalog needs to be backed up. The second special job would be run only should the machine running Dir need to be restored. The only thing special about these special jobs is that they always select a hardwired reserved volume. I am not a fan of relying on the availability of identical replacement hardware. In a disaster recovery, it is not unlikely that one would be forced to utilize whatever hardware is immediately available. Since this can affect number of disks, partitioning, etc., I prefer to install a minimal OS, along with Bacula and a SQL database server, and then restore the Dir. The install of Bacula creates an empty catalog database, or at least installs a script for creating one. The only thing that needs to be configured manually, then, is the initial SD config, which must have a Device for the archive device needed to mount the reserved volume. Then starting Dir and SD and running the special restore job restores the real config files and the catalog. The restored SD config will have to be manually edited to use the device nodes correct for the replacement machine. After restarting Dir and SD, the machine itself can then be restored in the usual way. -- 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
Re: [Bacula-users] Noob user impressions and why I chose not to use Bacula
Il 06/12/2011 11:15, James Harper ha scritto: >> The closest thing to a custom "eject tape" builtin command in bconsole > I >> could came up with is this: >> >> # admin job to manually eject tape from within bconsole Job { >> Name = "TapeEject" >> Type = Admin >> FileSet = "LinuxDefaultSet" >> Client = serverlinux-fd >> Storage = Tape >> Pool = Tape >> Messages = Standard >> RunBeforeJob = "echo 'umount storage=Tape' | bconsole" >> RunAfterJob = "mt-st -f /dev/nst0 offl" >> } >> >> This works on my setup, where I have a single tape drive (LTO-1, for > the >> record). No autochanger. >> > > It also supposes that the tape drive is local to the director, and not > connected to another machine. > > james You're right. I should have mentioned it. Thanks. -- Marcello Romani -- 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
Re: [Bacula-users] Noob user impressions and why I chose not to use Bacula
> The closest thing to a custom "eject tape" builtin command in bconsole I > could came up with is this: > > # admin job to manually eject tape from within bconsole Job { > Name = "TapeEject" > Type = Admin > FileSet = "LinuxDefaultSet" > Client = serverlinux-fd > Storage = Tape > Pool = Tape > Messages = Standard > RunBeforeJob = "echo 'umount storage=Tape' | bconsole" > RunAfterJob = "mt-st -f /dev/nst0 offl" > } > > This works on my setup, where I have a single tape drive (LTO-1, for the > record). No autochanger. > It also supposes that the tape drive is local to the director, and not connected to another machine. james -- 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
Re: [Bacula-users] Noob user impressions and why I chose not to use Bacula
Il 06/12/2011 10:07, Phil Stracchino ha scritto: > On 12/06/11 03:10, Marcello Romani wrote: >> Il 05/12/2011 03:39, Jesse Molina ha scritto: >> >> [snip food for thought] >> >> The closest thing to a custom "eject tape" builtin command in bconsole I >> could came up with is this: >> >> # admin job to manually eject tape from within bconsole >> Job { >> Name = "TapeEject" >> Type = Admin >> FileSet = "LinuxDefaultSet" >> Client = serverlinux-fd >> Storage = Tape >> Pool = Tape >> Messages = Standard >> RunBeforeJob = "echo 'umount storage=Tape' | bconsole" >> RunAfterJob = "mt-st -f /dev/nst0 offl" >> } >> >> This works on my setup, where I have a single tape drive (LTO-1, for the >> record). No autochanger. > > > You know, personally I just set "OfflineOnUnmount = yes". > > > Didn't know about that. Thank you. -- Marcello Romani -- 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
Re: [Bacula-users] Noob user impressions and why I chose not to use Bacula
On 12/06/11 03:10, Marcello Romani wrote: > Il 05/12/2011 03:39, Jesse Molina ha scritto: > > [snip food for thought] > > The closest thing to a custom "eject tape" builtin command in bconsole I > could came up with is this: > > # admin job to manually eject tape from within bconsole > Job { > Name = "TapeEject" > Type = Admin > FileSet = "LinuxDefaultSet" > Client = serverlinux-fd > Storage = Tape > Pool = Tape > Messages = Standard > RunBeforeJob = "echo 'umount storage=Tape' | bconsole" > RunAfterJob = "mt-st -f /dev/nst0 offl" > } > > This works on my setup, where I have a single tape drive (LTO-1, for the > record). No autochanger. You know, personally I just set "OfflineOnUnmount = yes". -- Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355 ala...@caerllewys.net ala...@metrocast.net p...@co.ordinate.org Renaissance Man, Unix ronin, Perl hacker, SQL wrangler, Free Stater It's not the years, it's the mileage. -- 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
Re: [Bacula-users] Noob user impressions and why I chose not to use Bacula
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" > 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
Re: [Bacula-users] Noob user impressions and why I chose not to use Bacula
Il 05/12/2011 03:39, Jesse Molina ha scritto: [snip food for thought] The closest thing to a custom "eject tape" builtin command in bconsole I could came up with is this: # admin job to manually eject tape from within bconsole Job { Name = "TapeEject" Type = Admin FileSet = "LinuxDefaultSet" Client = serverlinux-fd Storage = Tape Pool = Tape Messages = Standard RunBeforeJob = "echo 'umount storage=Tape' | bconsole" RunAfterJob = "mt-st -f /dev/nst0 offl" } This works on my setup, where I have a single tape drive (LTO-1, for the record). No autochanger. -- Marcello Romani -- 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
Re: [Bacula-users] Noob user impressions and why I chose not to use Bacula
On Mon, Dec 5, 2011 at 11:36 AM, 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. > > >Well, the first problem here is that the Director would have to know how > >much space it was going to need for BSR files. Of course, it could > >pre-allocate a fixed-size block of, say, 1MB for BSR files. > > Agree, 1 MB is basically nothing on a tape and it can accommodate easily a > huge amount of bsr files. > My /etc/bacula is 88k uncompressed. > > >The second problem, it seems to me, is that this would break > >compatibility with all older Bacula volumes and installations. > > not necessarily if you make this information at the beginning of the tape > look like a "volume file". > It will be ignored by old directors because it will look the same as a > failed job that took space on the tape. > > > Pablo > Or you could just decide that backward compatibility of that type is just not that important. For instance: versions x.0.0 and later use this format. Tapes written in this format are not accessible to older versions. It's OK to do that. It's also OK to have the option of writing in the older format from the newer directors. This will give you time to bring all your directors up to date before switching to the new format. -- 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
Re: [Bacula-users] Noob user impressions and why I chose not to use Bacula
>> 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. >Well, the first problem here is that the Director would have to know how >much space it was going to need for BSR files. Of course, it could >pre-allocate a fixed-size block of, say, 1MB for BSR files. Agree, 1 MB is basically nothing on a tape and it can accommodate easily a huge amount of bsr files. My /etc/bacula is 88k uncompressed. >The second problem, it seems to me, is that this would break >compatibility with all older Bacula volumes and installations. not necessarily if you make this information at the beginning of the tape look like a "volume file". It will be ignored by old directors because it will look the same as a failed job that took space on the tape. Pablo -- 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
Re: [Bacula-users] Noob user impressions and why I chose not to use Bacula
On 12/05/11 10:58, 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. Well, the first problem here is that the Director would have to know how much space it was going to need for BSR files. Of course, it could pre-allocate a fixed-size block of, say, 1MB for BSR files. The second problem, it seems to me, is that this would break compatibility with all older Bacula volumes and installations. -- Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355 ala...@caerllewys.net ala...@metrocast.net p...@co.ordinate.org Renaissance Man, Unix ronin, Perl hacker, SQL wrangler, Free Stater It's not the years, it's the mileage. -- 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
Re: [Bacula-users] Noob user impressions and why I chose not to use Bacula
On Mon, Dec 5, 2011 at 3:12 AM, Bruno Friedmann wrote: > On 12/05/2011 03:39 AM, Jesse Molina wrote: >> >> 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. >> >> -- > [snip..] > > Thanks Jesse for sharing this testimony. > > Sometimes like a punch in the mouth, especially a Monday morning with the > first coffee. :-) > > Some important points revealed. > > To respect your wishes about no answer or comment, I will shut up > And this is hard, just prove me how much I like bacula :-) a :( I was expecting to see a good flame-throwing thread coming out of all of this... Seriously, I think that, maybe the original author is not asking for answers, but it could be productive to discuss some of the things he says (in a productive way). Ildefonso. -- 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
Re: [Bacula-users] Noob user impressions and why I chose not to use Bacula
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" 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
Re: [Bacula-users] Noob user impressions and why I chose not to use Bacula
On 12/05/2011 03:39 AM, Jesse Molina wrote: > > 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. > > -- [snip..] Thanks Jesse for sharing this testimony. Sometimes like a punch in the mouth, especially a Monday morning with the first coffee. :-) Some important points revealed. To respect your wishes about no answer or comment, I will shut up And this is hard, just prove me how much I like bacula :-) -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member & Ambassador GPG KEY : D5C9B751C4653227 irc: tigerfoot -- 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
[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 care