Ok after looking at the code, it
appears that using the restore options “select most recent backup” and
“select backup for client before date” have a lot of built in
assumptions about configuration for a client.
For a more complex setup, it
looks like instead of building the tree list from the most recent full forward
(without checking to see that the incrementals / differentials are even based
on that job), it needs to instead build the list based on the most recent
backup (possibly selecting from the different jobs / filesets), then look for
all possible (full / diff / inc) parents needed to restore that job.
I have a hard time calling that
a bug though, just a difference of design philosophy.
I guess in the meantime until
this gets rethought, or I get ambitious enough to patch the code myself, I need
to just build my restore jobids manually, or try using bat to do restores, as
the CLI seems rather basic in its restore logic (understandably).
-Blake
From:
bacula-users-bounces AT lists.sourceforge DOT net
[mailto:bacula-users-bounces AT lists.sourceforge DOT net] On Behalf Of Blake
Dunlap
Sent: Thursday, June 26, 2008 10:47 AM
To: bacula-users AT lists.sourceforge DOT net
Subject: [Bacula-users] Possible Bug
I think I have found a possible bug either with restores, or
incremental backup full job selection.
I currently run two jobs per client due to lack of copy pool
support. The offsite backup has the word “WeeklyOffsite-“ in front
of the normal job name.
When I just tried to run a restore using the most recent
backup of a client, it picked the incrementals from the normal job, and the
full backup from the offsite job (not the full of the normal job). I am looking
at the code and former logs now to trace down if it is only restore related, or
the incrementals are being made against the wrong job.
I’m holding on filing a bug report until I can
determine which this is. The reason I am posting this is to see if anyone else
has seen similar issues.
-Blake
