Am 18.05.2011 13:08, schrieb Graham Keeling:
> On Wed, May 18, 2011 at 01:02:08PM +0200, Christian Manal wrote:
>> Am 18.05.2011 12:26, schrieb Graham Keeling:
>>> On Wed, May 18, 2011 at 11:54:18AM +0200, Christian Manal wrote:
>>>> Am 18.05.2011 11:13, schrieb Graham Keeling:
>>>>> If times don't explain it, take a look at this bacula code from
>>>>> src/cats/sql_get.c (function db_accurate_get_jobids()), which is getting
>>>>> the jobids from the database. You should be able to construct very similar
>>>>> queries and run them by hand to see what the database says.
>>>>> Or add some debug to get the exact sql queries being used.
>>>>>
>>>>> /* First, find the last good Full backup for this job/client/fileset */
>>>>> <snip>
>>>>
>>>> Thank you. The problem seems to be that the query doesn't account for
>>>> the job name it is supposed to do, just the client and fileset. I have
>>>> two jobs with the same fileset for each client. One backs up to local
>>>> storage with a full/diff/incr cycle and a rather long retention period,
>>>> the other does monthly full backups to another building for DR and gets
>>>> immediately purged.
>>>>
>>>> I enabled accurate for the onsite job but the query returns the last
>>>> full run of the offsite job. When I add "AND Name = '<JobName>'" to the
>>>> query it gets the right jobid.
>>>>
>>>> I think this qualifies for a bug, doesn't it?
>>>
>>> I agree with you, but...
>>> I have just remembered coming across this before. The thread starts here:
>>> http://www.mail-archive.com/bacula-devel AT lists.sourceforge DOT
>>> net/msg04050.html
>>>
>>> Kern:
>>> "Bacula does not support this option."
>>>
>>> Me:
>>> "It does appear to be *trying* to support it, as some parts of the code that
>>> figure out dependent jobs take note of the job name, though others do not."
>>>
>>> Kern:
>>> "I wouldn't exactly say that it is trying to support it, but rather that
>>> since
>>> the program is so complicated, and I try not to restrict it too much, there
>>> are places where it can seem to work, but it is just not designed to do so
>>> (at least at the moment), and thus it will not work. It isn't that I don't
>>> want it to work, but there is only so much that the developers can do in
>>> the
>>> time we have.
>>>
>>> Unfortunate what you are trying to do is simply not possible in the way you
>>> are trying to do it with the current code."
>>
>> Great... so I have to create two identical filesets to get this to work?
>
> Or add "AND Name = '<JobName>'", as was your idea. Maybe it works fine.\
Well, going by the thread you linked I just noticed that there is also
the issue of Bacula using the wrong jobs to create the restore filetree.
I'd rather not find out what else is affected by this and just do what
works. I also lack the c(++) skills to look further into this, I'm afraid.
Regards,
Christian Manal
>
>> If this kind of setup is not supported, it would be nice if I'd get at
>> least a warning by './bacula-dir -t' or something.
>>
>> Thanks for the help, though, I'll fix my config.
>>
>>
>> Regards,
>> Christian Manal
>>
>>
>>>
>>>
>>>
>>>> Regards,
>>>> Christian Manal
>>>>
>>>> ------------------------------------------------------------------------------
>>>> What Every C/C++ and Fortran developer Should Know!
>>>> Read this article and learn how Intel has extended the reach of its
>>>> next-generation tools to help Windows* and Linux* C/C++ and Fortran
>>>> developers boost performance applications - including clusters.
>>>> http://p.sf.net/sfu/intel-dev2devmay
>>>> _______________________________________________
>>>> Bacula-users mailing list
>>>> Bacula-users AT lists.sourceforge DOT net
>>>> https://lists.sourceforge.net/lists/listinfo/bacula-users
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> What Every C/C++ and Fortran developer Should Know!
>>> Read this article and learn how Intel has extended the reach of its
>>> next-generation tools to help Windows* and Linux* C/C++ and Fortran
>>> developers boost performance applications - including clusters.
>>> http://p.sf.net/sfu/intel-dev2devmay
>>> _______________________________________________
>>> Bacula-users mailing list
>>> Bacula-users AT lists.sourceforge DOT net
>>> https://lists.sourceforge.net/lists/listinfo/bacula-users
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> What Every C/C++ and Fortran developer Should Know!
>> Read this article and learn how Intel has extended the reach of its
>> next-generation tools to help Windows* and Linux* C/C++ and Fortran
>> developers boost performance applications - including clusters.
>> http://p.sf.net/sfu/intel-dev2devmay
>> _______________________________________________
>> Bacula-users mailing list
>> Bacula-users AT lists.sourceforge DOT net
>> https://lists.sourceforge.net/lists/listinfo/bacula-users
>
>
> ------------------------------------------------------------------------------
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its
> next-generation tools to help Windows* and Linux* C/C++ and Fortran
> developers boost performance applications - including clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Bacula-users mailing list
> Bacula-users AT lists.sourceforge DOT net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
>
------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
