Hi Andrea, Have you heard about Virtual Autochanger? There is a very good white paper about at: http://blog.bacula.org/whitepapers/CommunityDiskBackup.pdf.
Better than thinking about one storage device per host, I recommend you having a virtual autochanger with all your devices defined (it could be about 200 devices, maybe more than the number of hosts you expect to have). This way, you will always have a device available for a host backup job. And then you think about having "pools per hosts" (Host1FullPool, Host1DiffPool, Host2FullPoll, etc.), instead of having storages devices per hosts. This way, when your host goes away, you can just delete the pool that contains its volumes. Regards, Ana On Fri, Oct 24, 2014 at 10:26 AM, Andrea Carpani < andrea.carp...@dnshosting.it> wrote: > 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. > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users > >
------------------------------------------------------------------------------
_______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users