Bacula-users

Re: [Bacula-users] Restore problem out of the blue - scratch pool is suddenly "invalid"

2017-01-14 21:26:46
Subject: Re: [Bacula-users] Restore problem out of the blue - scratch pool is suddenly "invalid"
From: Phil Stracchino <phils AT caerllewys DOT net>
To: Kern Sibbald <kern AT sibbald DOT com>, bacula-users <bacula-users AT lists.sourceforge DOT net>
Date: Sat, 14 Jan 2017 21:25:26 -0500
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