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.

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.

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.

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.

Best regards,
Kern





On 01/14/2017 07:19 PM, Phil Stracchino wrote:
> I have a problem.  I need to restore a single directory of files.  I
> have the required tape volume mounted, I set up the job, no problem,
> until I exit file selection.
>
> Then suddenly, bacula (7.4.4) tells me:
>
> 1,179 files selected to be restored.
>
> Pool "Scratch" not valid.
> Job not run.
> *
>
>
> ...Wait, what?  None of the needed volumes are in the scratch pool, the
> bsr file does not contain any mention of it, none of my pools or job
> definitions have changed in years, and my last restore worked fine.  But
> suddenly I can't do a restore because suddenly my scratch pool that the
> restore doesn't even *touch* is "invalid".
>
> Here's the Scratch pool definition, which hasn't changed in at least
> five years:
>
> Pool {
>    Name = Scratch
>    Storage = babylon4-file
>    Pool Type = Backup
> }
>
>
> Does anyone have the slightest idea what's going on here, or why Bacula
> suddenly cares about the scratch pool which it isn't even using for this
> job, but is perfectly happy to recycle expired disk volumes into?
>
>
>
>


------------------------------------------------------------------------------
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 AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users