No, it doesn't run the before/after of all the jobs being copied for me (only
for the copy job itself).
It might help if you post the full copy job output rather than just the error
message to show the full sequence of events.
__Martin
>>>>> On Tue, 6 Sep 2022 15:02:50 +0200, Justin Case said:
>
> I have that on 2 backup jobs that are copied, but not on the copy job itself.
> doe copy jobs run the before/after of all the jobs being copied?
>
> > On 6. Sep 2022, at 13:02, Martin Simmons <mar...@lispworks.com> wrote:
> >
> > Maybe you have a run before/after directive that is causing it to run a
> > bconsole command?
> >
> > __Martin
> >
> >
> >>>>>> On Mon, 5 Sep 2022 21:02:52 +0200, Justin Case said:
> >>
> >> It works for me, too, but I get this error.
> >>
> >>> On 5. Sep 2022, at 20:14, Martin Simmons <mar...@lispworks.com> wrote:
> >>>
> >>> A copy job works for me in Bacula 13.0.0 without this problem (even if the
> >>> bacula-fd isn't running).
> >>>
> >>> __Martin
> >>>
> >>>
> >>>>>>>> On Mon, 5 Sep 2022 19:09:18 +0200, Justin Case said:
> >>>>
> >>>> Yes, it does match. I then replaced the dummy password with the actual
> >>>> FD password, and the error did not occur any more when starting copy
> >>>> jobs. This behaves differently than documented, that’s why I am asking.
> >>>>
>>>>> On 5. Sep 2022, at 17:56, Martin Simmons <mar...@lispworks.com> wrote:
>>>>>
>>>>> That looks strange to me. The "JobId 0" maybe means that it was caused by
>>>>> something else. Does the time "04-Sep 14:19" match the sequence of times
>>>>> in
>>>>> the other messages about the copy job?
>>>>>
>>>>> __Martin
>>>>>
>>>>>
> >>>>>>>>>> On Sun, 4 Sep 2022 14:33:03 +0200, Justin Case said:
> >>>>>>
> >>>>>> Hi there,
> >>>>>>
> >>>>>> I took this snipped from the main documentation about copy jobs:
> >>>>>>
> >>>>>> # # Fake client for copy jobs #
> >>>>>> Client {
> >>>>>> Name = None
> >>>>>> Address = localhost
> >>>>>> Password = "NoNe”
> >>>>>> Catalog = MyCatalog
> >>>>>> }
> >>>>>>
> >>>>>> # # Default template for a CopyDiskToTape Job # JobDefs {
> >>>>>>
> >>>>>> Name = CopyDiskToTape
> >>>>>> Type = Copy
> >>>>>> Messages = StandardCopy
> >>>>>> Client = None
> >>>>>> FileSet = None
> >>>>>> Selection Type = PoolUncopiedJobs
> >>>>>> Maximum Concurrent Jobs = 10
> >>>>>> SpoolData = No
> >>>>>> Allow Duplicate Jobs = Yes
> >>>>>> Cancel Queued Duplicates = No
> >>>>>> Cancel Running Duplicates = No
> >>>>>> Priority = 13
> >>>>>> }
> >>>>>>
> >>>>>> It says: "The Copy Job runs without using the File daemon by copying
> >>>>>> the data from the old backup Volume to a different Volume in a
> >>>>>> different Pool.” So there is no need for a working Client.
> >>>>>>
> >>>>>> This does not seem to be entirely factual. I configured it as
> >>>>>> suggested above, but then the Director gives me:
> >>>>>>
> >>>>>> 04-Sep 14:19 bacula-dir JobId 0: Fatal error: authenticatebase.cc:435
> >>>>>> Director unable to authenticate with File Daemon at "localhost:9102".
> >>>>>> Possible causes: Passwords or names not the same or
> >>>>>>
> >>>>>> The copy job still works, but I think it is not suitable to provoke
> >>>>>> such an error.
> >>>>>>
> >>>>>> Why would the Director actually connect to the client? May I suppress
> >>>>>> this?
> >>>>>>
> >>>>>> Thanks for considering my question,
> >>>>>> J/C
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Bacula-users mailing list
> >>>>>> Bacula-users@lists.sourceforge.net
> >>>>>> https://lists.sourceforge.net/lists/listinfo/bacula-users
> >>>>>>
>>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >
>
>
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
