On Wed, Mar 11, 2009 at 08:48:34AM +0100, Bruno Friedmann wrote:
> 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
> >
> > 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.
> >
> >
>
> In fact to resume the whole thread, It's only a trouble if you choose the
> most recent backup for a client
> in restore.
>
> What you are doing is the same we do here (filesets/clients for fullWeek (1
> full, other are diff) and Month are identical but
> pools/stores and schedules are differents )
I don't think that is quite the same.
I had this (before I gave in and duplicated the FileSet)...
Client: C
FileSet: F
Job: myjob1 Job: myjob2
Storage: S1 Storage: S2
Full Pool: FP1 Full Pool: FP2
Diff Pool: DP1 Diff Pool: DP2
Incr Pool: IP1 Incr Pool: IP2
Schedule: Sch1 Schedule: Sch2
It turns out that some parts of bacula differentiate between myjob1 and myjob2,
and some parts don't. The thing that is consistent is that it differentiates
on the Client/FileSet pair.
So, for example, it ends up basing a myjob1 incremental backup on a myjob2
differential...
> When we need to restore we use the option 3 ( list of jobids to restore ) and
> we manually choose all jobids
> used for a simple pool. list jobs etc are our friends.
>
> With doing that we never encounter a trouble.
...so, if I were to manually pick out all the JobIds for the backups that went
to Storage S1, I would not get a consistent set.
If I left it to bacula to decide what a consistent set was, it would pick
a mixture of fulls/differentials/incrementals from both storages. It would then
be unable to restore them because it is currently unable to restore from more
than one storage in a single restore job (as explained in another email
thread that I started last week).
As an aside, I think a very useful option in the bconsole restore menu would
be to be able to select a single JobId and have bacula work out and select
the dependent jobs from it.
At the moment, you either have to laboriously type in a date that is greater
than the date of the backup that you want and is less than the subsequent
backup (bacula then figures out the dependent jobs), or manually figure out all
the jobIds that you want by yourself.
------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel
