From: Andrea C. <and...@dn...> - 2014-10-24 13:27:13
|
On 24/10/2014 14:55, Bryn Hughes 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 > Ok, so I guess my need to reload it's conf often might come from the fact that I'm using it in a wrong way: I have no tape whatsoever, but a 40TB disk array I want to use to backup ~100 hosts. My plan was to use a separate directory (i.e.: storage device) to keep backups for each server. Each "storage device" would contain backup files (volumes) grouped in a "Volume pool" (one for each host). Ideally each volume includes data for a single job, but we can skip this for now. I want such setup because hosts come and go and I want to be able to easily delete backup files and reclaim disk space if a host is dismissed. Can someone suggest me a better way to manage this? Regards Andrea .a.c. |