Restore problem out of the blue - scratch pool is suddenly "invalid"

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Restore problem out of the blue - scratch pool is suddenly "invalid"

Phil Stracchino-2
I have a problem.  I need to restore a single directory of files.  I
have the required tape volume mounted, I set up the job, no problem,
until I exit file selection.

Then suddenly, bacula (7.4.4) tells me:

1,179 files selected to be restored.

Pool "Scratch" not valid.
Job not run.
*


...Wait, what?  None of the needed volumes are in the scratch pool, the
bsr file does not contain any mention of it, none of my pools or job
definitions have changed in years, and my last restore worked fine.  But
suddenly I can't do a restore because suddenly my scratch pool that the
restore doesn't even *touch* is "invalid".

Here's the Scratch pool definition, which hasn't changed in at least
five years:

Pool {
  Name = Scratch
  Storage = babylon4-file
  Pool Type = Backup
}


Does anyone have the slightest idea what's going on here, or why Bacula
suddenly cares about the scratch pool which it isn't even using for this
job, but is perfectly happy to recycle expired disk volumes into?




--
  Phil Stracchino
  Babylon Communications
  [hidden email]
  [hidden email]
  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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Restore problem out of the blue - scratch pool is suddenly "invalid"

Phil Stracchino-2
On 01/14/17 13:19, Phil Stracchino wrote:
> Does anyone have the slightest idea what's going on here, or why Bacula
> suddenly cares about the scratch pool which it isn't even using for this
> job, but is perfectly happy to recycle expired disk volumes into?

Oh, and it's also perfectly happy to delete expired volumes from the
"invalid" scratch pool.

I can only guess that this is an uncaught regression in some recent
Bacula release.  But which release...?

I'm trying backing out my director to 7.4.3.


--
  Phil Stracchino
  Babylon Communications
  [hidden email]
  [hidden email]
  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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Restore problem out of the blue - scratch pool is suddenly "invalid"

Phil Stracchino-2
On 01/14/17 13:49, Phil Stracchino wrote:

> On 01/14/17 13:19, Phil Stracchino wrote:
>> Does anyone have the slightest idea what's going on here, or why Bacula
>> suddenly cares about the scratch pool which it isn't even using for this
>> job, but is perfectly happy to recycle expired disk volumes into?
>
> Oh, and it's also perfectly happy to delete expired volumes from the
> "invalid" scratch pool.
>
> I can only guess that this is an uncaught regression in some recent
> Bacula release.  But which release...?
>
> I'm trying backing out my director to 7.4.3.


CONFIRMED:  This is a regression in Bacula 7.4.4.


--
  Phil Stracchino
  Babylon Communications
  [hidden email]
  [hidden email]
  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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Restore problem out of the blue - scratch pool is suddenly "invalid"

Kern Sibbald
In reply to this post by Phil Stracchino-2
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.

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.

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.

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.

Best regards,
Kern





On 01/14/2017 07:19 PM, Phil Stracchino wrote:

> I have a problem.  I need to restore a single directory of files.  I
> have the required tape volume mounted, I set up the job, no problem,
> until I exit file selection.
>
> Then suddenly, bacula (7.4.4) tells me:
>
> 1,179 files selected to be restored.
>
> Pool "Scratch" not valid.
> Job not run.
> *
>
>
> ...Wait, what?  None of the needed volumes are in the scratch pool, the
> bsr file does not contain any mention of it, none of my pools or job
> definitions have changed in years, and my last restore worked fine.  But
> suddenly I can't do a restore because suddenly my scratch pool that the
> restore doesn't even *touch* is "invalid".
>
> Here's the Scratch pool definition, which hasn't changed in at least
> five years:
>
> Pool {
>    Name = Scratch
>    Storage = babylon4-file
>    Pool Type = Backup
> }
>
>
> Does anyone have the slightest idea what's going on here, or why Bacula
> suddenly cares about the scratch pool which it isn't even using for this
> job, but is perfectly happy to recycle expired disk volumes into?
>
>
>
>


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Restore problem out of the blue - scratch pool is suddenly "invalid"

Phil Stracchino-2
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
  [hidden email]
  [hidden email]
  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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Restore problem out of the blue - scratch pool is suddenly "invalid"

Kern Sibbald
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Restore problem out of the blue - scratch pool is suddenly "invalid"

Phil Stracchino-2
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
  [hidden email]
  [hidden email]
  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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Restore problem out of the blue - scratch pool is suddenly "invalid"

Phil Stracchino-2

Removed Storage from the Scratch pool definition.
Updated the Scratch pool from resource.
Re-updated director from 7.4.3 to 7.4.4
Re-entered the restore job.  Job failed with the same
invalid-scratch-pool message.


cwd is: /
$ cd /home/alaric
cwd is: /home/alaric/
$ cd ".moonchild productions"
cwd is: /home/alaric/.moonchild productions/
$ cd "pale moon"
cwd is: /home/alaric/.moonchild productions/pale moon/
$ mark alaric
1,207 files marked.
$ exit
Bootstrap records written to /var/lib/bacula/minbar-dir.restore.1.bsr
Bootstrap records written to /var/lib/bacula/minbar-dir.restore.1.bsr

The Job will require the following (*=>InChanger):
   Volume(s)                 Storage(s)                SD Device(s)
===========================================================================

    LTO4-FULL-0013            babylon5-sd               LTO-4
    DIFF-20170109-04:30       babylon4-file             FileStorage
    INCR-20170115-04:30       babylon4-file             FileStorage

Volumes marked with "*" are in the Autochanger.


1,210 files selected to be restored.

Using Catalog "Catalog"
Pool "Scratch" not valid.
Job not run.
You have messages.
*llist volume=LTO4-FULL-0013
          MediaId: 48
       VolumeName: LTO4-FULL-0013
             Slot: 0
           PoolId: 6
        MediaType: LTO-4
      MediaTypeId: 0
...
    ScratchPoolId: 0
    RecyclePoolId: 0
...

*llist volume=DIFF-20170109-04:30
          MediaId: 1,991
       VolumeName: DIFF-20170109-04:30
             Slot: 0
           PoolId: 4
        MediaType: File
      MediaTypeId: 0
...
    ScratchPoolId: 0
    RecyclePoolId: 1
...

*llist volume=INCR-20170115-04:30
          MediaId: 1,997
       VolumeName: INCR-20170115-04:30
             Slot: 0
           PoolId: 5
        MediaType: File
      MediaTypeId: 0
...
    ScratchPoolId: 0
    RecyclePoolId: 1
...

*list pools
+--------+-------------+---------+---------+----------+---------------------------------------------------------------------------------------+
| PoolId | Name        | NumVols | MaxVols | PoolType | LabelFormat
                                                                     |
+--------+-------------+---------+---------+----------+---------------------------------------------------------------------------------------+
|      1 | Scratch     |       1 |       0 | Backup   | *
                                                                     |
|      2 | VirtualFull |       0 |       0 | Backup   |
VIRTUAL-$Year${Month:p/2/0/r}${Day:p/2/0/r}-${Hour:p/2/0/r}:${Minute:p/2/0/r}-$Client
|
|      3 | Full-Disk   |       0 |       0 | Backup   |
FULL-$Year${Month:p/2/0/r}${Day:p/2/0/r}-${Hour:p/2/0/r}:${Minute:p/2/0/r}
           |
|      4 | Diff-Disk   |       6 |       0 | Backup   |
DIFF-$Year${Month:p/2/0/r}${Day:p/2/0/r}-${Hour:p/2/0/r}:${Minute:p/2/0/r}
           |
|      5 | Incr-Disk   |      27 |       0 | Backup   |
INCR-$Year${Month:p/2/0/r}${Day:p/2/0/r}-${Hour:p/2/0/r}:${Minute:p/2/0/r}
           |
|      6 | Full-Tape   |      21 |      24 | Backup   | LTO4-FULL-
                                                                     |
+--------+-------------+---------+---------+----------+---------------------------------------------------------------------------------------+




I do notice that the scratch pool ID for all of these pools is 0.  There
is no pool with id 0, and in fact I am not setting a Scratch pool for
any of my pools.  Could this be the problem?



--
  Phil Stracchino
  Babylon Communications
  [hidden email]
  [hidden email]
  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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Restore problem out of the blue - scratch pool is suddenly "invalid"

Kern Sibbald
Hello Phil,

It is a bit late here so I will look at all your output tomorrow, but if
you have the patience, go to:

<bacula>/src/dird/ua_run.c
then at line 1074, you should have the following lines of code:

    /* Not a good idea to start a job with the Scratch pool */
    if (rc.pool && strcmp(rc.pool->name(), NT_("Scratch")) == 0) {
       ua->send_msg(_("Pool \"Scratch\" not valid.\n"));
       return false;
    }

Just delete all those lines (or if you want, only the "return false;"),
but be careful to leave the next line, which
reads:

    return true;

===

That should resolve your problem.

Best regards,
Kern

On 01/15/2017 07:56 PM, Phil Stracchino wrote:

> Removed Storage from the Scratch pool definition.
> Updated the Scratch pool from resource.
> Re-updated director from 7.4.3 to 7.4.4
> Re-entered the restore job.  Job failed with the same
> invalid-scratch-pool message.
>
>
> cwd is: /
> $ cd /home/alaric
> cwd is: /home/alaric/
> $ cd ".moonchild productions"
> cwd is: /home/alaric/.moonchild productions/
> $ cd "pale moon"
> cwd is: /home/alaric/.moonchild productions/pale moon/
> $ mark alaric
> 1,207 files marked.
> $ exit
> Bootstrap records written to /var/lib/bacula/minbar-dir.restore.1.bsr
> Bootstrap records written to /var/lib/bacula/minbar-dir.restore.1.bsr
>
> The Job will require the following (*=>InChanger):
>     Volume(s)                 Storage(s)                SD Device(s)
> ===========================================================================
>
>      LTO4-FULL-0013            babylon5-sd               LTO-4
>      DIFF-20170109-04:30       babylon4-file             FileStorage
>      INCR-20170115-04:30       babylon4-file             FileStorage
>
> Volumes marked with "*" are in the Autochanger.
>
>
> 1,210 files selected to be restored.
>
> Using Catalog "Catalog"
> Pool "Scratch" not valid.
> Job not run.
> You have messages.
> *llist volume=LTO4-FULL-0013
>            MediaId: 48
>         VolumeName: LTO4-FULL-0013
>               Slot: 0
>             PoolId: 6
>          MediaType: LTO-4
>        MediaTypeId: 0
> ...
>      ScratchPoolId: 0
>      RecyclePoolId: 0
> ...
>
> *llist volume=DIFF-20170109-04:30
>            MediaId: 1,991
>         VolumeName: DIFF-20170109-04:30
>               Slot: 0
>             PoolId: 4
>          MediaType: File
>        MediaTypeId: 0
> ...
>      ScratchPoolId: 0
>      RecyclePoolId: 1
> ...
>
> *llist volume=INCR-20170115-04:30
>            MediaId: 1,997
>         VolumeName: INCR-20170115-04:30
>               Slot: 0
>             PoolId: 5
>          MediaType: File
>        MediaTypeId: 0
> ...
>      ScratchPoolId: 0
>      RecyclePoolId: 1
> ...
>
> *list pools
> +--------+-------------+---------+---------+----------+---------------------------------------------------------------------------------------+
> | PoolId | Name        | NumVols | MaxVols | PoolType | LabelFormat
>                                                                       |
> +--------+-------------+---------+---------+----------+---------------------------------------------------------------------------------------+
> |      1 | Scratch     |       1 |       0 | Backup   | *
>                                                                       |
> |      2 | VirtualFull |       0 |       0 | Backup   |
> VIRTUAL-$Year${Month:p/2/0/r}${Day:p/2/0/r}-${Hour:p/2/0/r}:${Minute:p/2/0/r}-$Client
> |
> |      3 | Full-Disk   |       0 |       0 | Backup   |
> FULL-$Year${Month:p/2/0/r}${Day:p/2/0/r}-${Hour:p/2/0/r}:${Minute:p/2/0/r}
>             |
> |      4 | Diff-Disk   |       6 |       0 | Backup   |
> DIFF-$Year${Month:p/2/0/r}${Day:p/2/0/r}-${Hour:p/2/0/r}:${Minute:p/2/0/r}
>             |
> |      5 | Incr-Disk   |      27 |       0 | Backup   |
> INCR-$Year${Month:p/2/0/r}${Day:p/2/0/r}-${Hour:p/2/0/r}:${Minute:p/2/0/r}
>             |
> |      6 | Full-Tape   |      21 |      24 | Backup   | LTO4-FULL-
>                                                                       |
> +--------+-------------+---------+---------+----------+---------------------------------------------------------------------------------------+
>
>
>
>
> I do notice that the scratch pool ID for all of these pools is 0.  There
> is no pool with id 0, and in fact I am not setting a Scratch pool for
> any of my pools.  Could this be the problem?
>
>
>


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Restore problem out of the blue - scratch pool is suddenly "invalid"

Phil Stracchino-2
On 01/15/17 16:34, Kern Sibbald wrote:

> Hello Phil,
>
> It is a bit late here so I will look at all your output tomorrow, but if
> you have the patience, go to:
>
> <bacula>/src/dird/ua_run.c
> then at line 1074, you should have the following lines of code:
>
>     /* Not a good idea to start a job with the Scratch pool */
>     if (rc.pool && strcmp(rc.pool->name(), NT_("Scratch")) == 0) {
>        ua->send_msg(_("Pool \"Scratch\" not valid.\n"));
>        return false;
>     }
>
> Just delete all those lines (or if you want, only the "return false;"),
> but be careful to leave the next line, which
> reads:
>
>     return true;
>
> ===
>
> That should resolve your problem.

That does indeed resolve the problem.  I've attached my exact patch.


--
  Phil Stracchino
  Babylon Communications
  [hidden email]
  [hidden email]
  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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users

bacula-7.4.4-disable-scratch-pool-check.patch (800 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Restore problem out of the blue - scratch pool is suddenly "invalid"

Kern Sibbald
In reply to this post by Phil Stracchino-2
Hello Phil,

I have not yet figured out what is going wrong here, or what triggered
Bacula to think it is trying to use a Volume directly from the Scratch
pool.  I am going to look at the code in more detail to see if I can
find the problem.  In any case, I am planning to remove the code as in
my view it appears more likely to create problems rather than solve
them.  The only thing that I see that is related to the Scratch pool is
the Recycle pool so I am going to look at the code from that stand
point, but recycling into the Scratch pool is quite OK to do.

You should not need to directly reference the Scratch pool as you ask
below.

Would you mind attaching your Director's Job and Restore Resources and a
copy of any resource that it points to?  I suspect that the normal
mechanism of setting up to run a job finds a Pool to be used for a
"backup" job even though in this case it is a restore job, and perhaps
somewhere along the line, the Pool is marked to be Scratch.  Just to
repeat, even if a reference to the Scratch pool happens, this code
causes Bacula to malfunction.

Best regards,
Kern

On 01/15/2017 07:56 PM, Phil Stracchino wrote:

> Removed Storage from the Scratch pool definition.
> Updated the Scratch pool from resource.
> Re-updated director from 7.4.3 to 7.4.4
> Re-entered the restore job.  Job failed with the same
> invalid-scratch-pool message.
>
>
> cwd is: /
> $ cd /home/alaric
> cwd is: /home/alaric/
> $ cd ".moonchild productions"
> cwd is: /home/alaric/.moonchild productions/
> $ cd "pale moon"
> cwd is: /home/alaric/.moonchild productions/pale moon/
> $ mark alaric
> 1,207 files marked.
> $ exit
> Bootstrap records written to /var/lib/bacula/minbar-dir.restore.1.bsr
> Bootstrap records written to /var/lib/bacula/minbar-dir.restore.1.bsr
>
> The Job will require the following (*=>InChanger):
>     Volume(s)                 Storage(s)                SD Device(s)
> ===========================================================================
>
>      LTO4-FULL-0013            babylon5-sd               LTO-4
>      DIFF-20170109-04:30       babylon4-file             FileStorage
>      INCR-20170115-04:30       babylon4-file             FileStorage
>
> Volumes marked with "*" are in the Autochanger.
>
>
> 1,210 files selected to be restored.
>
> Using Catalog "Catalog"
> Pool "Scratch" not valid.
> Job not run.
> You have messages.
> *llist volume=LTO4-FULL-0013
>            MediaId: 48
>         VolumeName: LTO4-FULL-0013
>               Slot: 0
>             PoolId: 6
>          MediaType: LTO-4
>        MediaTypeId: 0
> ...
>      ScratchPoolId: 0
>      RecyclePoolId: 0
> ...
>
> *llist volume=DIFF-20170109-04:30
>            MediaId: 1,991
>         VolumeName: DIFF-20170109-04:30
>               Slot: 0
>             PoolId: 4
>          MediaType: File
>        MediaTypeId: 0
> ...
>      ScratchPoolId: 0
>      RecyclePoolId: 1
> ...
>
> *llist volume=INCR-20170115-04:30
>            MediaId: 1,997
>         VolumeName: INCR-20170115-04:30
>               Slot: 0
>             PoolId: 5
>          MediaType: File
>        MediaTypeId: 0
> ...
>      ScratchPoolId: 0
>      RecyclePoolId: 1
> ...
>
> *list pools
> +--------+-------------+---------+---------+----------+---------------------------------------------------------------------------------------+
> | PoolId | Name        | NumVols | MaxVols | PoolType | LabelFormat
>                                                                       |
> +--------+-------------+---------+---------+----------+---------------------------------------------------------------------------------------+
> |      1 | Scratch     |       1 |       0 | Backup   | *
>                                                                       |
> |      2 | VirtualFull |       0 |       0 | Backup   |
> VIRTUAL-$Year${Month:p/2/0/r}${Day:p/2/0/r}-${Hour:p/2/0/r}:${Minute:p/2/0/r}-$Client
> |
> |      3 | Full-Disk   |       0 |       0 | Backup   |
> FULL-$Year${Month:p/2/0/r}${Day:p/2/0/r}-${Hour:p/2/0/r}:${Minute:p/2/0/r}
>             |
> |      4 | Diff-Disk   |       6 |       0 | Backup   |
> DIFF-$Year${Month:p/2/0/r}${Day:p/2/0/r}-${Hour:p/2/0/r}:${Minute:p/2/0/r}
>             |
> |      5 | Incr-Disk   |      27 |       0 | Backup   |
> INCR-$Year${Month:p/2/0/r}${Day:p/2/0/r}-${Hour:p/2/0/r}:${Minute:p/2/0/r}
>             |
> |      6 | Full-Tape   |      21 |      24 | Backup   | LTO4-FULL-
>                                                                       |
> +--------+-------------+---------+---------+----------+---------------------------------------------------------------------------------------+
>
>
>
>
> I do notice that the scratch pool ID for all of these pools is 0.  There
> is no pool with id 0, and in fact I am not setting a Scratch pool for
> any of my pools.  Could this be the problem?
>
>
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Bacula-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Loading...