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