Hello, OK, this is a big improvement. Now, let's get a bit closer to the problem. You have specified that srv-erh01 is a problem, but I see no problem for it. So, for that particular job (srv-erh01), please supply the following:
1. The original backup JobId. 2. The name of the job that migrated it. 3. The JobIds involved in the migration. 4. The job report output from the migration jobs. Regards, Kern On Friday 20 July 2007 20:32, Gustavo Gibson da Silva wrote: > 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 > >>> Bacula-users@lists.sourceforge.net > >>> 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
