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 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 > ------------------------------------------------------------------------- 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
