On 01/14/17 16:36, Kern Sibbald wrote: > Hello Phil, > > Someone apparently someone submitted the following comment to a bug report: > > ==== > Currently, a scratch pool is uses as any other pool. In particula, it is > possible to use a scratch pool as a target for backups. The result may > be quite unexpected and annoying. > > One solution would be that the DIR refuses to run a job where the target > pool is called "Scratch" OR the target pool has a PoolId that is used in > any other pool as Scratch Pool, i.e. where a query like > select count(*) from pool where > scratchpoolid=<thepoolforthecurrentbackup>; > returns more than 0. > ==== > > The recommendation was made to forbid a backup going into the Scratch > pool. This was implemented in the Enterprise version and part of what > was back ported.
So a pool named Scratch cannot have type Backup? Is there a separate Scratch pool type now? At the time it was created, if memory serves it had to be a backup pool because there was no other valid type. > My comment is that I am not sure it is such a good idea to prohibit > users from backing up directly to the Scratch pool, and in any case, the > code that was implemented applies to *any* kind of Job. Now for this to > happen, > you must someplace have mentioned the Scratch pool, possibly in your > Restore, or by the fact that used a Storage definition in your Scratch > pool resource. The pools containing the disk volumes required for the restore have Scratch set as their Recycle pool. That is the only connection. > I am not 100% why you have a Storage directive in your Scratch pool, so > I would be interested in your comments. However, this Storage > directive is probably the source of the problem, and could probably be > fixed by removing it. I couldn't tell you offhand why there's a Storage directive in the Scratch pool. My guess would be that it was required at the time the pool was created, and so I assigned it the same storage device as the pools any volume that could be recycled into it. What is the *minimum* that is actually required in a scratch pool definition? I'm totally OK with changing the pool definition. > Having said that, the code is just plain broken because, even if one can > admit that it is a good idea to prohibit backups directly to the Scratch > pool, at least the code should restrict itself to apply only to backup > Jobs. The code was added in August 2016. And all backups are working perfectly. Only this restore had a problem. I think this is the first time I've needed to run a restore since updating to 7.4.4. -- Phil Stracchino Babylon Communications ph...@caerllewys.net p...@co.ordinate.org Landline: 603.293.8485 ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
