On 01/15/17 02:35, Kern Sibbald wrote:
> Sorry, I did not explain the problem clearly enough.  For some reason (I 
> hope to find out Monday), doing backups directly to a Scratch pool (i.e. 
> the Scratch pool is directly referenced in the Job) do or can lead to 
> problems.

Yeah, I can see that backing up to a scratch pool could be a bad idea.

>  So the idea of the person submitting the bug report and the 
> person that implemented it was to forbid backing up directly to a 
> Scratch pool.  That doesn't mean that the backup cannot use a Volume 
> that came from the Scratch pool.
> 
> There has always been a Pool Type, but it has never been implemented 
> other than the directive is there, but the value is never used.  I still 
> have plans for the Pool Type though.

OK.  Perhaps add a Scratch pool type then?

>> The pools containing the disk volumes required for the restore have
>> Scratch set as their Recycle pool.  That is the only connection.
> 
> Having the Scratch set in a Recycle pool should not be a problem.
> 
> Could you do an "llist" of the volume(s) chosen to be restored?  I just 
> want to be 100% sure the Volume is not currently in the Scratch pool.  I 
> think, but I am not sure, that the problem may be your Storage directive 
> in the Scratch pool.

There aren't *any* volumes currently in the Scratch pool.  All volumes
required for the backup were in one of three pools:  Full-Tape,
Diff-Disk, Incr-Disk.


> Pool {   /* required items */
>     Name
>     Pool Type
> }
> 
> So, unless I am missing something, you could remove the Storage 
> directive.  If you do that, please let me know if it fixes the problem.

I'll give it a try right now and update back to 7.4.4.  (I had to back
out to 7.4.3 to perform the backup.)

> I am about 90% sure I am going to remove the code that caused you 
> problems, but I want to check with the authors first.  At a minimum, it 
> should not apply to restore jobs and if I leave it there rather than 
> abruptly ending the run, I will probably make it a warning. However, 
> until I understand what the authors wanted, I prefer to wait a bit and 
> collect a bit more info from you (Pools of Volumes needed for restore 
> and possibly removing the Storage directive from the pool definition).





-- 
  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