Hello Phil,
Please see below ...
On 01/15/2017 03:25 AM, Phil Stracchino wrote:
> 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.
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. 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.
>
>
>> 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.
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.
>
>
>> 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.
Well, that makes sense.
>
> What is the *minimum* that is actually required in a scratch pool
> definition? I'm totally OK with changing the pool definition.
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 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).
>
>
>> 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.
>
>
Yes, I do not run restores often (about once or twice a year), but when
I do, I want them to work. When they don't it is instant panic (at
least for me and luckily it does not last long).
Best regards,
Kern
------------------------------------------------------------------------------
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
|
