Glad you got it working! The 2 jobs is easy to explain:
The MigrateDCIM-to-Tape job could more reasonably be called a "Copy Control" job. It's task is to orchestrate the work done by the job it launches (job ID 8 in the most recent instance from your email). JID8 is a clone of JID4 in almost every way (down to the joblog), except for details that must differ, like storage resource used. Bacula is making a true copy of JID4 in JID8, which could stand in for JID4 if it were impossible to use for recovery. But why two jobs? JID7 is running things behind the scenes. For every copy job like JID 8, there must be a copy control job. they run together, and terminate together. If your copy control job had found multiple eligible backup jobs to copy, it would have spawned n-1 copy control jobs, and taken the last backup job itself. If you had 4 eligible jobs ready to be copied, you'd end up with 8 jobs launched - 4 copy control, 4 actually doing the copying. Please note that bacula doesn't use the term "copy control" internally. It just calls each job a copy job, which is confusing. Copy Control is something Bill A uses to explain this behavior, and I've found that language useful as well. Robert Gerber 402-237-8692 [email protected] On Mon, Dec 8, 2025, 12:56 AM Kevin Buckley < [email protected]> wrote: > 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 >
_______________________________________________ Bacula-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-users
