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 ph...@caerllewys.net p...@co.ordinate.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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users