I am going to disagree with Bryn and Ana. The only reason to agree is human
error and how the current SD configuration is implemented. Based on the number
of queries on this list for managing devices, human error is prone to be high,
and as for the SD configuration it is a static manual configuration file. I'd
prefer a dynamic interactive SD interface that permits adding/removing devices
on-the-fly. It's a harder implementation and a total rewrite. So, reloading
the config file, once due diligence has been done on the OS level, should be
permitted and it should replace what is currently in memory. Displaying a
before/after config and requiring confirmation on the reload would "save" some
folks.
Patti Clark
Linux System Administrator
R&D Systems Support Oak Ridge National Laboratory
865-576-7718
From: "Ana Emília M. Arruda" <emiliaarruda AT gmail DOT com<mailto:emiliaarruda
AT gmail DOT com>>
Date: Friday, October 24, 2014 at 9:20 AM
Cc: "Bacula-users AT lists.sourceforge DOT net<mailto:Bacula-users AT
lists.sourceforge DOT net>" <bacula-users AT lists.sourceforge DOT
net<mailto:bacula-users AT lists.sourceforge DOT net>>
Subject: Re: [Bacula-users] Configuration reload for bacula-sd
Hi all,
I totally agree with Bryn. Even more when you think about your volumes. Bacula
links volumes to devices and it is not a really good idea so frequent changes
(deleting devices from bacula-sd.cionf) in your devices. This way you will have
lots of trouble with volumes that does not have its device anymore. You should
be aware of migrating these jobs before deleting devices from your
bacula-sd.conf all the time.
Best regards,
Ana
On Fri, Oct 24, 2014 at 9:55 AM, Bryn Hughes <linux AT nashira DOT
ca<mailto:linux AT nashira DOT ca>> wrote:
On 14-10-24 05:28 AM, Andrea Carpani wrote:
On 24/10/2014 12:47, Kern Sibbald wrote:
No, the SD and the FD cannot be reloaded. On the FD in principle it
would be easy, but on the SD, it would be complicated if drives
changed. What would you do with Jobs that are using a drive that
would be removed from the reload?
I'm not that deep into backup software, so maybe I'm saying something
stupid, but a config reload could do the same thing that other software
do, that is:
- continue servicing current requests with the previous conf and
- use the new conf for new requests.
Something like a graceful restart apache does.
Does this make sense?
.a.c.
Sense to humans yes, sense to program code not so much.
The nature of the SD is that its configuration should almost never change - all
it has for config is an inventory of hardware devices. There's a certain
elegance in simplicity that would be lost trying to cover what should be a
fairly narrow use case.
Imagine all the debugging you have to do - is this job failing because it is
trying to use the config as it appears in the config file, or some other config
in memory from some time in the past? What happens if we now have different
device names referring to the same physical device, we now need a whole locking
mechanism that can cover the use case of multiple versions of the SD config
accessing the same physical device, possibly with different parameters and
names. How would you be able to tell which version of the config a given job
is using? Remember it is easy to start a backup job that can last a couple of
days - a full backup of a huge fileserver for instance.
Things would get really messy really fast, with practically no benefit. Your
SD config likely changes what, once or twice per year? If that? It is much
safer to just restart the SD when you have an idle period between backups.
Bryn
------------------------------------------------------------------------------
------------------------------------------------------------------------------
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
