#717 Issue closed: [FR] Specify Bacula jobid in confi

Labels: enhancement, support / question, needs sponsorship

hazcod opened issue at 2015-11-26 09:26:

Currently, the config allows us to specify the volume on beforehand but not the jobid.
(this is possible too in bootstrap.txt of bextract)

It would be good if we could specify the JobId too in the configuration file, so an almost-automatic disaster recovery CD can be built.

gdha commented at 2015-11-26 15:10:

@HazCod Dag and Jeroen wrote the Bacula integration, but they are not active currently within the rear project. So, no clue who could assist you with the feature request?

gdha commented at 2016-02-19 11:16:

@HazCod Could you explain with an example?

hazcod commented at 2016-02-19 11:22:

@gdha As far as I know, when booting the recovery CD for bacula, you need to select the jobid. If we could include that in our config too, users could just insert the CD and it would recover automatically.
( no user-driven decisions needed )

Jobids here are ids of the backup jobs done by bacula, e.g.:
001 today at 12:00
002 today at 13:00
003 todat at 14:00

So if I want to generate a disaster recovery ISO for the latest backup, I would just fill in the last known JobId (003) in the config file and generate the ISO.

gdha commented at 2016-02-19 11:24:

@HazCod sounds indeed interesting to keep. Are you able to prepare a pull request for this?

hazcod commented at 2016-02-19 13:40:

Not at the moment as i'm currently not using rear in my situation, I'm afraid

jsmeix commented at 2016-09-28 14:08:

I neither use Bacula nor Bareos but according to what I read in
https://github.com/rear/rear/pull/997
there is meanwhile support for a variable
named BAREOS_RESTORE_JOB
which seems to be support for a Bareos job ID.

According to
https://www.bareos.org/en/
"Bareos is a ... fork of the backup project from bacula.org"
which indicates that support for a Bacula job ID
could be implemented in a similar way.

But https://github.com/rear/rear/issues/717#issuecomment-186216176
indicates that at least for now this will not be implemented
so that I close this issue now.

If needed it could be reopened but preferably
a new issue based on a current rear version
should be submitted.


[Export of Github issue for rear/rear.]