Kern Sibbald escreveu:
> Hello,
>
> Thanks for the output.
>
> However, the volume is rather big; if you want this issue to get some
> attention, rather than make me spend a lot of time searching through your
> output, It certainly would help a lot if you pointed me to the exact jobids
> that you feel are failing as I did in my email to you.
>
> Best regards,
>
> Kern
>
Hi,
One example is srv-erh01, the one I've got the select statement from,
however the same error occurs on:
srv-gisanet
pinguim
wivox
spock
newton
BTW I think I've found something interesting: There is a migration job
running right now. I've noticed that the select statement works
perfectly for srv-gisanet because it hasn't been migrated yet. By
executing the slighlty changed statement:
SELECT * FROM Job WHERE JobStatus='T' AND Type='B' AND Level='F' AND
Name='srv-gisanet' AND ClientId=36 AND FileSetId=21 ORDER BY StartTime DESC;
I get only:
| 9721 | srv-gisanet.2007-07-20_02.00.23 | srv-gisanet | B | F |
36 | T | 2007-07-20 02:00:22 | 2007-07-20 05:26:08 |
2007-07-20 06:27:50| 2007-07-20 06:27:50 | 1184923670 | 216 |
1184362380 | 5556 |533459016 | 0 | 0 |
18 | 21 | 0 | 0 | 0 |
But if I run a select for all reccords of srv-gisanet I get the
following (only the interesting part):
| 9646 | srv-gisanet.2007-07-19_02.00.23 | srv-gisanet | M | F |
36 | T | 2007-07-19 02:00:22 | 2007-07-19 04:29:50 |
2007-07-19 05:30:29| 2007-07-19 05:30:29 | 1184833829 | 165 |
1184362380 | 5461 |532990056 | 0 | 0 |
17 | 21 | 0 | 1 | 0 |
| 9658 | srv-gisanet.2007-07-19_08.00.06 | srv-gisanet | B | F |
36 | T | 2007-07-19 08:00:05 | 2007-07-19 04:29:50 |
2007-07-19 05:30:29| 2007-07-19 10:54:38 | 1184833829 | 173 |
1184362380 | 5461 |527212382 | 0 | 0 |
11 | 18 | 9646 | 0 | 0 |
| 9721 | srv-gisanet.2007-07-20_02.00.23 | srv-gisanet | B | F |
36 | T | 2007-07-20 02:00:22 | 2007-07-20 05:26:08 |
2007-07-20 06:27:50| 2007-07-20 06:27:50 | 1184923670 | 216 |
1184362380 | 5556 |533459016 | 0 | 0 |
18 | 21 | 0 | 0 | 0 |
The thing I've noticed is that the line of the job 9646 (with Type=M)
contains the same FileSetId of the job 9721 (with Type=B) and, as I
said, job 9721 hasn't been migrated yet. However there is this job 9658
(that is the New backup JobId according to the migration log bellow) has
Type=B but the FileSetId is different. For migration jobs I use a
placebo Fileset named "Arquivos" as I have only one migration job
defined. Have I messed up something here?
Thank you.
Gustavo.
19-Jul 10:54 srv-backup03-dir: Bacula 2.0.3 (06Mar07): 19-Jul-2007 10:54:38
Prev Backup JobId: 9646
New Backup JobId: 9658
Migration JobId: 9657
Migration Job: MigraPFita.2007-07-19_08.00.05
Backup Level: Full
Client: srv-backup03-fd
FileSet: "Arquivos" 2007-04-18 08:00:01
Read Pool: "Segunda" (From Job resource)
Read Storage: "File" (From Pool resource)
Write Pool: "Quinta-f" (From Job Pool's NextPool resource)
Write Storage: "DDS-4" (From Storage from Pool's NextPool
resource)
Start time: 19-Jul-2007 10:47:53
End time: 19-Jul-2007 10:54:38
Elapsed time: 6 mins 45 secs
Priority: 20
SD Files Written: 5,461
SD Bytes Written: 527,212,382 (527.2 MB)
Rate: 1301.8 KB/s
Volume name(s): INET-QUI-0007
Volume Session Id: 173
Volume Session Time: 1184362380
Last Volume Bytes: 8,070,773,760 (8.070 GB)
SD Errors: 0
SD termination status: OK
Termination: Migration OK
> On Friday 20 July 2007 17:17, Gustavo Gibson da Silva wrote:
>> Kern Sibbald escreveu:
>>> Hello,
>>>
>>> I am unable to duplicate this problem, and suspect that there is some
>>> other problem such as confusion between the original backup job name and
>>> the name of the migration Job. Below, you will see that the migration job
>>> is named "migrate-job" and the job to be migrated is
> named "MigrationJobSave".
>>> All Migrated jobs already have Type='B' so the proposed solution of
> checking
>>> for 'M' is not correct.
>>>
>> Hi,
>>
>> Attached you will find the jobs of this week and bacula-dir.conf as
>> well. Notice that the select exerpt from the log refers to the server
>> srv-erh01.
>>
>> The backup routine is:
>>
>> Mondays - Full
>> Tu,We,Th - Incremental
>> Fr - Differential
>>
>> Thank you,
>>
>> Gustavo.
>>
>>> Here is a job listing of a Migration that I just did:
>>>
>>> list jobs
>>>
> +-------+------------------+---------------------+------+-------+----------+-------------+-----------+
>>> | JobId | Name | StartTime | Type | Level |
> JobFiles | JobBytes | JobStatus |
> +-------+------------------+---------------------+------+-------+----------+-------------+-----------+
>>> | 1 | MigrationJobSave | 2007-07-20 10:40:46 | M | F |
> 7,336 | 133,686,677 | T |
>>> | 5 | MigrationJobSave | 2007-07-20 10:40:46 | B | F |
> 7,336 | 134,833,665 | T |
>>> | 2 | MigrationJobSave | 2007-07-20 10:40:49 | M | F |
> 7,336 | 133,686,677 | T |
>>> | 6 | MigrationJobSave | 2007-07-20 10:40:49 | B | F |
> 7,336 | 134,833,665 | T |
>>> | 4 | migrate-job | 2007-07-20 10:41:01 | g | F |
> 0 | 0 | T |
>>> | 3 | migrate-job | 2007-07-20 10:41:04 | g | F |
> 0 | 0 | T |
>>> | 7 | MigrationJobSave | 2007-07-20 10:41:11 | B | I |
> 0 | 0 | T |
> +-------+------------------+---------------------+------+-------+----------+-------------+-----------+
>>> In the above, I ran two full backups (JobId=1,2) Then a migration job
> (JobId=3,4) which
>>> produced the Migrated output JobId=6. Note, jobids=1,2 were both marked
> as migrated,
>>> type='M' and the resulting migrated job JobId=6 is marked with type='B' as
> they should.
>>> And finally, I ran an Incremental backup, which since
>>> I had not modified any files backed up nothing. If it had been upgraded,
> it would have
>>> backed up everything.
>>>
>>> If you still think there is a problem, at a *minimum*, I'll need a job
> listing equivalent to
>>> the above plus the bacula-dir.conf file so I can see the parameters that
> were set
>>> for migration.
>>>
>>> Best regards,
>>>
>>> Kern
>>>
>>>
>>> On Friday 20 July 2007 00:27, Arno Lehmann wrote:
>>>> Hi,
>>>>
>>>> 19.07.2007 23:55,, Gustavo Gibson da Silva wrote::
>>>>> Hi there,
>>>>>
>>>>> I've noticed that full backup jobs that are migrated are not considered
>>>>> as a Backup job. So I get the following message:
>>>> Uh oh... if that's true then you found a major problem, I think... I'm
>>>> forwarding this to the -devel list, too, as they surely want to know
>>>> about something like this shortly before releasing the next version...
>>>>
>>>>> 13-Jul 02:00 srv-backup03-dir: sql_find.c:134 No Job record found: ERR=
>>>>> CMD=SELECT StartTime FROM Job WHERE JobStatus='T' AND Type='B' AND
>>>>> Level='F' AND Name='srv-erh01' AND ClientId=15 AND FileSetId=27 ORDER BY
>>>>> StartTime DESC LIMIT 1
>>>>>
>>>>> However I've noticed that it works if I change the select statement to
>>>>> insert ( Type='B' or Type='M') so the statement above becomes:
>>>>>
>>>>> SELECT StartTime FROM Job WHERE JobStatus='T' AND ( Type='B' OR
>>>>> Type='M') AND Level='F' AND Name='srv-erh01' AND ClientId=15 AND
>>>>> FileSetId=27 ORDER BYStartTime DESC LIMIT 1;
>>>>>
>>>>> +---------------------+
>>>>> | StartTime |
>>>>> +---------------------+
>>>>> | 2007-07-19 02:29:33 |
>>>>> +---------------------+
>>>>>
>>>>> As I am no bacula or SQL expert, have I understood the statement
>>>>> correctly?
>>>> I think so, but I'm not a migration expert :-)
>>>>
>>>>> If so how does it get fixed on bacula?
>>>> Should be a rather simple change somewhere in cats/sql_find.c and / or
>>>> the files where the function db_find_job_start_time() is used. Perhaps.
>>>>
>>>> Arno
>>>>
>>>>> Thank you.
>>>>>
>>>>> Gustavo.
>>>>>
>>>>>
>>>> --
>>>> Arno Lehmann
>>>> IT-Service Lehmann
>>>> www.its-lehmann.de
>>>>
>>>> -------------------------------------------------------------------------
>>>> This SF.net email is sponsored by: Microsoft
>>>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>> _______________________________________________
>>>> Bacula-devel mailing list
>>>> [email protected]
>>>> https://lists.sourceforge.net/lists/listinfo/bacula-devel
>>>>
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>> _______________________________________________
>>> Bacula-users mailing list
>>> [EMAIL PROTECTED]
>>> https://lists.sourceforge.net/lists/listinfo/bacula-users
>>>
>>>
>>
>> --
>> "Nam et ipsa scientia potestas est"
>>
>> -- Sir Francis Bacon, 1597
>>
>
>
--
"Nam et ipsa scientia potestas est"
-- Sir Francis Bacon, 1597
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bacula-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-devel
