On Monday 09 March 2009 18:39:49 Graham Keeling wrote:
> On Mon, Mar 09, 2009 at 05:56:36PM +0100, Kern Sibbald wrote:
> > On Monday 09 March 2009 17:40:15 Graham Keeling wrote:
> > > Hello,
> > >
> > > I have come across some problems involving a single client, a single
> > > fileset, and more than one job definition.
> > >
> > > My setup...
> > >
> > > Client: myclient
> > > FileSet: myfileset
> > >
> > > Job: myjob1
> > > Job: myjob2
> >
> > Bacula does not support this option.
>
> I don't believe that this is made very clear in the documentation.
Yes, that is very likely the case, but with a program as complex as Bacula and
already 800 pages of free documentation ...
>
> 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.
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.
Regards,
Kern
>
> > > myjob1 and myjob2 both backup myclient using myfileset, but the
> > > schedules, pools, and storages differ.
> > >
> > >
> > > I run an Incremental backup using myjob1 and wait for it to finish.
> > > It gets upgraded to a Full backup:
> > > ("No prior or suitable Full backup found in catalog. Doing FULL
> > > backup.")
> > >
> > > I add a file called '/var/log/zzz'.
> > > I run an Incremental backup using myjob2 and wait for it to finish.
> > > It gets upgraded to a Full backup:
> > > ("No prior or suitable Full backup found in catalog. Doing FULL
> > > backup.")
> > >
> > > The fact that they both got upgraded to Full backups indicates that
> > > they are independent of each other.
> > >
> > > I delete the file called '/var/log/zzz'.
> > > I run an Incremental backup using myjob1.
> > >
> > >
> > > So, I have:
> > >
> > > myjob1 | myjob2
> > > ------------------
> > > 1: Full |
> > >
> > > | 2: Full (contains '/var/log/zzz')
> > >
> > > 3: Incr |
> > >
> > > Now, if I attempt a restore - for example, the most recent backup for a
> > > client, bacula chooses JobIds 2 and 3.
> > > It should have chosen JobIds 1 and 3.
> > >
> > > When the storages for myjob1 and myjob2 are different, it
> > > then hits the 'cannot restore from multiple storages' problem and the
> > > restore job gets stuck 'waiting for a mount request'.
> > > When the storages are the same, it happily restores from JobIds 2 and
> > > 3, which is logically the wrong thing to do.
> > >
> > >
> > > Since the two initial Full backups distinguished between the defined
> > > jobs, and the restore does not, I think this is a bug. So I
> > > investigated further.
> > >
> > > Using 'bls', I found that JobId 3 actually took note of the deletion of
> > > '/var/log/zzz'. After looking at the source code, I found that there
> > > are at least four different places, using different functions, where it
> > > tries to figure out which jobs go together.
> > >
> > > These are:
> > > a) dird/fd_cmds.c: get_level_since_time()
> > > This uses cats/sql_find.c: db_find_job_start_time(),
> > > which checks the job Name, ClientId, and the FileSet.
> > > b) dird/ua_restore.c: select_backup_before_date()
> > > This uses SQL commands defined in cats/sql_cmds.c that look at the
> > > ClientId, the FileSet and the StartTime.
> > > c) dird/backup.c: send_accurate_current_files()
> > > dird/vbackup.c: do_vbackup()
> > > These both use cats/sql_get.c: db_accurate_get_jobids(),
> > > which checks the ClientId, the FileSet and the StartTime.
> > >
> > > It is logical to me that these should all be checking the job Name.
> > >
> > > (As an aside: It seems to me that all of this would be much simpler,
> > > less error-prone and non-ambiguous if each job recorded the jobId that
> > > it was based on in the database)
> > >
> > > Graham.
> > >
> > >
> > > -----------------------------------------------------------------------
> > >---- --- Open Source Business Conference (OSBC), March 24-25, 2009, San
> > > Francisco, CA -OSBC tackles the biggest issue in open source: Open
> > > Sourcing the Enterprise -Strategies to boost innovation and cut costs
> > > with open source participation -Receive a $600 discount off the
> > > registration fee with the source code: SFAD
> > > http://p.sf.net/sfu/XcvMzF8H
> > > _______________________________________________
> > > Bacula-devel mailing list
> > > Bacula-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/bacula-devel
>
> ---------------------------------------------------------------------------
>--- Open Source Business Conference (OSBC), March 24-25, 2009, San
> Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing
> the Enterprise -Strategies to boost innovation and cut costs with open
> source participation -Receive a $600 discount off the registration fee with
> the source code: SFAD http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Bacula-devel mailing list
> Bacula-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bacula-devel
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel
