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