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 )
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.
--
Bruno Friedmann
------------------------------------------------------------------------------
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
