I've often thought that bacula copy jobs (the ones actually copying the data) were quite a bit like bacula was "replaying" the original backup job, only involving the relevant SD(s) and not the FD.
Robert Gerber 402-237-8692 [email protected] On Mon, Dec 8, 2025, 1:17 AM Rob Gerber <[email protected]> wrote: > 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
