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.
Which option are you referring to?
Multiple jobs with the same FileSet and Client?
>> 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)
--
Dan Langille
BSDCan - The Technical BSD Conference : http://www.bsdcan.org/
PGCon - The PostgreSQL Conference: http://www.pgcon.org/
------------------------------------------------------------------------------
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
