Bacula-users

Re: [Bacula-users] Migrated Monthly Backups not seen by Dailies.

2008-05-16 15:51:32
Subject: Re: [Bacula-users] Migrated Monthly Backups not seen by Dailies.
From: Martin Simmons <martin AT lispworks DOT com>
To: doug AT jshfarms DOT com
Date: Fri, 16 May 2008 19:52:03 +0100
>>>>> On Fri, 16 May 2008 08:26:47 -0700, Doug Breshears said:
> 
> Martin Simmons wrote:
> >>>>>> On Wed, 07 May 2008 16:43:43 -0700, Doug Breshears said:
> >>>>>>             
> >> Martin Simmons wrote:
> >>     
> >>>>>>>> On Wed, 07 May 2008 09:25:10 -0700, Doug Breshears said:
> >>>>>>>>             
> >>>>>>>>                 
> >>>> Hi all,
> >>>>
> >>>> I have a Monthly Full backup that backs up to a DISK FILE, Then Migrate 
> >>>> to Tape. I then do a daily backup which should look at the last Full 
> >>>> backup. However the daily process is saying it cannot find a valid FULL 
> >>>> backup to compare to.
> >>>>
> >>>> I have included the pertinent sections from the log file to show the 
> >>>> progress of this one Job resource ("Full Set").
> >>>> I would appreciate any feedback here letting me know what I am doing 
> >>>> wrong.
> >>>>
> >>>> --------------------------------------------------------------------------------------
> >>>> Time Frame:
> >>>>
> >>>>     I started the Full Backup Friday Eve (May 02),
> >>>>     I started Migration Monday Morn (May 05) (after setting volume
> >>>>     status to FULL),
> >>>>     Migration went all day and ended Tuesday,
> >>>>     Enabled regular daily backups Tuesday so it started Wednesday ~1am.
> >>>>     
> >>>>         
> >>> Looks like it might be a bug.
> >>>
> >>> What is the output of the following sql command for those jobs?
> >>>
> >>> select jobid, job, name, type, level, jobstatus from job where jobid in 
> >>> (4301,4300,4292);
> >>>
> >>> __Martin
> >>>   
> >>>       
> >> Interesting.. I will have to look at the DB more closely.
> >> Here is the data...
> >>
> >> *sqlquery
> >> Automatically selected Catalog: MyCatalog
> >> Using Catalog "MyCatalog"
> >> Entering SQL query mode.
> >> Terminate each query with a semicolon.
> >> Terminate query mode with a blank line.
> >> Enter SQL query: select jobid, job, name, type, level, jobstatus from 
> >> job where jobid in (4301, 4300, 4292);
> >> +-------+-------------------------------------+-----------------+------+-------+-----------+
> >> | jobid | job                                 | name            | type | 
> >> level | jobstatus |
> >> +-------+-------------------------------------+-----------------+------+-------+-----------+
> >> | 4292  | Ex1.2008-05-02_17.36.37             | Ex1             | M    | F 
> >>     | T         |
> >> | 4300  | Migrate-Monthly.2008-05-05_08.18.01 | Migrate-Monthly | g    | F 
> >>     | T         |
> >> | 4301  | Ex1.2008-05-05_08.18.02             | Ex1             | B    | F 
> >>     | T         |
> >> +-------+-------------------------------------+-----------------+------+-------+-----------+
> >> Enter SQL query:
> >>     
> >
> > Ok, so the correct jobs are still in the catalog.  I think the
> > differential/incremental backups are suppose to find jobid 4301 after
> > migration.
> >
> > The output of
> >
> > select jobid, ClientId, FileSetId, StartTime from job where jobid in (4301, 
> > 4292);
> >
> > would be useful to check that the other important fields are correct.
> >
> > The actual query used by Bacula will be
> >
> > SELECT StartTime FROM Job WHERE JobStatus='T' AND Type='B'
> >        AND Level='F' AND Name='Ex1'
> >        AND ClientId=$TheClientId
> >        AND FileSetId=$TheFileSetId
> >        ORDER BY StartTime DESC LIMIT 1;
> >
> > with $TheClientId and $TheFileSetId replaced by the appropriate numbers.  It
> > should find jobid 4301 after the migration.  Prior to the migration, it 
> > should
> > find jobid 4292.
> >
> > __Martin
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> > Don't miss this year's exciting event. There's still time to save $100. 
> > Use priority code J8TL2D2. 
> > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> > _______________________________________________
> > Bacula-users mailing list
> > Bacula-users AT lists.sourceforge DOT net
> > https://lists.sourceforge.net/lists/listinfo/bacula-users
> >
> >
> > __________ NOD32 3090 (20080509) Information __________
> >
> > This message was checked by NOD32 antivirus system.
> > http://www.eset.com
> >
> >
> >
> >   
> Well I am not sure what the *correct* items for these fields would be 
> but I ran the query.
> It seems like the file sets should be the same but there are two 
> FileSetID's.
> 
> I ran the *Bacula Query as typed and came up with the following results. 
> It looks like it is finding everything.
> Does anything here show up as wrong?
> 
> *sql
> Automatically selected Catalog: MyCatalog
> Using Catalog "MyCatalog"
> Entering SQL query mode.
> Terminate each query with a semicolon.
> Terminate query mode with a blank line.
> Enter SQL query: select jobid, ClientId, FileSetId, StartTime from job 
> where jobid in (4301, 4292);
> +-------+----------+-----------+---------------------+
> | jobid | ClientId | FileSetId | StartTime           |
> +-------+----------+-----------+---------------------+
> | 4292  | 2        | 8         | 2008-05-02 17:36:40 |
> | 4301  | 2        | 11        | 2008-05-02 17:36:40 |
> +-------+----------+-----------+---------------------+
> 
> Enter SQL query: select StartTime FROM Job WHERE JobStatus='T' AND 
> Type='B' AND
> +---------------------+' AND ClientId=2 AND FileSetId=8 ORDER BY 
> StartTime DESC
> | StartTime           |
> +---------------------+
> | 2008-05-07 01:05:05 |
> +---------------------+
> 
> Enter SQL query: select StartTime FROM Job WHERE JobStatus='T' AND 
> Type='B' AND
> Level='F' and Name='Ex1' AND ClientId=2 AND FileSetId=11 ORDER BY 
> StartTime DESC
> +---------------------+
> | StartTime           |
> +---------------------+
> | 2008-05-02 17:36:40 |
> +---------------------+
> Enter SQL query:

I see that the original job has FileSetId=8, but the new backup job has
FileSetId=11.  When Bacula tries to find the previous Full job, I suspect that
it looks for a backup job with FileSetId=8, which it won't find now because
the original job has become a migrated job.  It should find the new backup job
(4301), but that will fail if the FileSetId is wrong.

What are these filesets?  I.e. what does the following print?

select * from fileset;

__Martin

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users