On Tue, May 04, 2010 at 11:43:32PM +0200, Michael Stapelberg wrote: > > (1) no way to do a simple client check (AKA amcheck -c.) > > (2) no way to do a simple tape check (AKA amcheck -lt) > What exactly do you mean with "client check" and "tape check"?
"client check" meaning that all clients are reachable with correct passwords and such. That is, communications are OK. I can run an "estimate" job, but this takes time, especially if the clients are busy and/or have a lot of files. It would be nice to be able to "test client client=$client" or "test client all". Similarly, "tape check" meaning that the next volume from the next scheduled pool is available. For example, if the next scheduled job would use the "daily" pool, check that there is a volume from "daily" available now, before it's needed. This is handy if, for example, you run backups at night, but you want to make sure that there will be no problems before you leave for the day. > > (4) no way to logically group hosts into a "run", with common options, the > > way amanda can. Somewhat solvable with scripting. > You can use template files and replace variables therein with sed, like this: > @"|sed 's/%name/client-1/g' /etc/bacula/client.tmpl" > While it looks ugly (especially with many variables), it’s a good method to > simplify your configuration considerably and keep boiler-plate to a minimum. Yes, I've written similar scripts to auto-generate client configs, daily jobs, and monthly jobs from a master file; hence my comment that it's somewhat solvable with scripting. IMHO, this is a workaround, not a solution. It should be possible to create jobs for a collection of hosts that run as a unit, report as a unit, and cancel as a unit rather than individually. > > (6) no proper client/server model. bacula "clients" need inbound ports > Why would one want a "proper" client/server model? Because it simplifies client firewall configs (people are more fussy about inbound connections than outbound), dynamic IP clients, and SSL/TLS configs (only bacula-dir and bacula-sd processes need certs instead of each bacula-fd.) > Not having the need to contact the director all the time is actually > good, IMO (you would have to do that when not having inbound > connections). I agree that polling is bad, but if I have to pick one poison, I'd rather have constant-on fd->dir connections or polling rather than dir->fd connections. Note that it's possible to get the best of both worlds by using fd->dir connections with polling and a "wake up" from dir->fd on another port. If the fd detects the wake-up, it does an out-of-cycle poll and lowers the poll frequency. Environments that can't allow dir->fd communication can disable the "wake-up". The "wake-up" doesn't need SSL/TLS. So, if you don't mind dir->fd communication, you leave "wake-up" enabled and still get simplified SSL/TLS configs. If you do mind dir->fd communication, you disable "wake-up" altogether and live with the poll. > Also, for the storage daemon it is quite clear that it needs inbound > connections Yes, I'd say that the dir and the sd count as server-side while the fd counts as client-side. The problem is dir->fd connections, not fd->sd connections. > > (7) no support for native backups. > What are "native backups"? backups using tools like ufsdump, dump, tar, cpio, etc. It would be nice if bacula let me pick whether to use native tools or its own format. In particular, that would simplify bare-metal recovery of the bacula director hosts without having to do a native-tool backup of the bacula directory outside of bacula. > > (8) no built-in support for fully-automated storage of recovery > > data. bacula recovery disks require a lot of manual work. > Not sure if I understand your point, but for a bacula recovery disk > you just need any linux live system (grml.org comes to mind) and > edit bacula-fd.conf exactly once. That’s not a lot of manual work, > IMO. What about the partition tables, LVM config, and the like? Bacula restore disks are recommended for a reason. > > (9) no support for TOFU authentication. Clients must be > > hand-configured. > What is TOFU authentication? What prevents you from using some > automated configuration system like puppet to roll out your config? TOFU == trust on first use, like ssh host keys. This is handy for imaged systems, such as Windows. Include a bacula FD client on the image configured for TOFU, and you don't need to do any manual config on the client system to support backups. While something like puppet is great, not having to configure it at all is even better. > > (12) bconsole should support an option for execute-one-command (i.e. -e) > You can pipe commands into bconsole. Yes, I already do that. However, one gets a bunch of header garbage and output formatted for interactive use. IME, *nix tools in bacula's class usually include an option for execute-once and an option for batch mode, which are designed for script rather than interactive use. > > (14) no support for "disable job=$job until $time" > You can use at(1) and bconsole, see above. That's a workaround that relies on the user/sysadmin to use external command-line tools. The functionality should be native to bacula so that it can be utilized in the GUI or web interfaces. NB: bconsole will actually allow one to use control-c, one just has to press it 4 times instead of once. - Morty ------------------------------------------------------------------------------ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
