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
