Re: Copy Job config help

On 2025/12/08 13:45, Kevin Buckley wrote:
> On 2025/12/08 12:59, Rob Gerber wrote:
>> 
>> On Sun, Dec 7, 2025, 10:52 PM Rob Gerber <[email protected]> wrote:
>> 
>>> Copy jobs are tricky to wrap ones head around, as you noted. I know I had
>>> trouble at first.
>>>
>>> The first things I'd try are:
>>>
>>> 1. The FileCP pool doesn't have a storage resource defined. In this case I
>>> think you'd want one pointing to FileCP. The FileCP pool cannot express
>>> which storage resource is appropriate for it, so when that pool is
>>> referenced the copy control job MigrateDCIM-to-Tape cannot figure out the
>>> correct device. It would be nice if the copy control job figured this out
>>> by looking through records for JobID 4, but that doesn't appear to be
>>> happening here.
>>>
>>> ...
>>>>>> Robert Gerber
>>> 402-237-8692
>>> [email protected]
>>
>> Oops, I made an error.
>> 
>> In point 1, your FileCP pool should point to its own storage resource,
>> which from your source job, appears to be "file2"
>> 
>> I always define the storage at the pool level. Retention is defined
>> there too.
> 
It appears that your Point 1 is one of the missing pieces here:

Adding in an explicit

   Storage = File2

to the FileCP Pool stanza, sees the following definition of
the Copy job:

Select Job resource (1-7): 5
Run Copy job
JobName:       MigrateDCIM-to-Tape
Bootstrap:     *None*
Client:        client-fd
FileSet:       DCIM Fileset
Pool:          FileCP (From Job resource)
NextPool:      TapeCP (From Job Pool's NextPool resource)
Read Storage:  File2 (From Pool resource)
Write Storage: TS4300 (From Job Pool's NextPool resource)
JobId:         *None*
When:          2025-12-08 13:57:31
Catalog:       MyCatalog
Priority:      10
OK to run? (Yes/mod/no):

and so the "Read Storage" target is now the "File Device" and
not a Tape.

Sync-ing that up has also removed the "cant find a tape in
a drive: label a new one" message too, in that I'm now told

OK to run? (Yes/mod/no): Yes

testinst-dir JobId 7: The following 1 JobId was chosen to be copied: 4
testinst-dir JobId 7: Copying using JobId=4 Job=BackupDCIM-to-FileCP.2025-12-04_16.25.22_03
testinst-dir JobId 7: Start Copying JobId 7, Job=MigrateDCIM-to-Tape.2025-12-08_14.02.49_05
testinst-dir JobId 7: Connected to Storage "TS4300" at testinst.pawsey.org.au:9103 with TLS
testinst-dir JobId 7: Connected to Storage "File2" at testinst.pawsey.org.au:9103 with TLS
testinst-dir JobId 7: Using Device "FileChgr2-Dev1" to read.
testinst-dir JobId 8: Using Device "TS4300-Drive1" to write.
testinst-sd JobId 8: Connected to Storage at clement.pawsey.org.au:9103 with TLS

although the TWO Jobs that have now been spawned,

Running Jobs:
Console connected using TLS at 08-Dec-25 13:57
  JobId  Type Level     Files     Bytes  Name              Status
======================================================================
      7  Copy Full          0         0  MigrateDCIM-to-Tape is running
      8  Back Full          0         0  BackupDCIM-to-FileCP is running


don't quite match what the messages suggest the jobs are doing,
in that JobID 7 is connected to BOTH the File and Tape Devices,
but JobId 8, which is usingthe Tape Drive to Write, is reportedly
running the BackupDCIM-to-FileCP Job, which should, if actually
running,  be Writing to a File Device.

Not sure why JobID 8 got started, nor why neither JobIDs 7 or 8 thinks
they are handling 0 Files/Bytes, either?

JobId 4, the original Backup Job, that is now the subject of the Copy
Job, JobID 7, handled

  JobId  Level     Files    Bytes    Status   Finished        Name
      4  Full      3,514    152.7 M  OK       04-Dec-25 16:25 BackupDCIM-to-FileCP

Kevin Buckley


_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users