Re: Spool Data per job type
Lloyd Brown <[email protected]> Tue, 14 Jul 2026 10:49:03 -0600
| Newsgroups | gmane.comp.bacula.user |
|---|---|
| Message-ID | <[email protected]> |
--===============2977807227839891614== Content-Type: multipart/alternative; boundary="------------7mPRxOqBeav0Owy1HTbUppEC" Content-Language: en-US --------------7mPRxOqBeav0Owy1HTbUppEC Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Yeah. That's the problem. I have enough disk to store the incrementals for the duration we want to, but not the fulls/differentials. That's the problem. I did consider having a "run after job" script that detects whether the job is a full/differential, and is on a disk pool, and immediately scheduling a migration to tape. I'm still not sure I have enough space for that, but at least it would get it off the disks ASAP. I can confirm that having the `spooldata=yes/no` does seem to work on the `run` lines in the schedule. It may depend on the release, but I'm running 15.0.3. My concern is less about that, and more about what happens when something breaks, eg. a full fails, and the subsequent incremental is upgraded automatically. Lloyd On 7/14/26 10:43, Rob Gerber wrote: > I wonder if spooldata = yes/no or a joddef resource can be given as a > parameter for a schedule line. Not sure. I don't have the bacula > manuals in front of me. > > Otherwise, if you have suitable disk space, you could write your full > and diff backups to disk, then copy or migrate them off to tape. Spool > data would be set off for the disk jobs, and set on for the > copy/migrate jobs. Migrate would be the strategy that frees disk space > as soon as possible, if you have enough disk to hold one round of > fulls, but not enough for all the fulls in your catalog. > > > Robert Gerber > 402-237-8692 > [email protected] > > On Tue, Jul 14, 2026, 11:33 AM Lloyd Brown <[email protected]> wrote: > > Hi, all. > > With my new Bacula 15 deployment, I'm running into something I'd > like to > do, but I don't think there's a feature for it yet. But before I > submit > a feature request, I wanted to sanity check, and see if anyone had an > alternative that I hadn't considered. > > Here's the deal. I have jobs that run Full, Differential and > Incremental jobs. The Full and Differential jobs are supposed to > go to > a tape pool, and should use data spooling. The Incremental jobs are > supposed to go to a disk pool, and should not use data spooling. The > job can have "Full Backup Pool", "Differential Backup Pool", etc., > defined, so different job types can end up in different pools. But > there's no similar job-type-specific "Spool Data" attribute, is there? > > Right now, I can handle this by putting in parameters in the > Schedule's > "run" lines. And if those jobs are successful, then great. But if > not > (eg. a Full has failed), then subsequent Incremental jobs might get > upgraded to be a Full. If I have the "Full Backup Pool" > specified, that > upgraded job would (I assume) end up in the right pool, but wouldn't > have the correct spooling set up. Or if I don't have the "Full > Backup > Pool" set, then it will end up in the disk pool, instead of the tape > pool, albeit with the appropriate spool behavior for the disk pool. > > I'll put an example of one of my jobs below, so you can tell me > what I > might be missing. Or I can explain again, if this isn't clear. > > > Thanks, > > Lloyd > > > > Example job: > > > Job { > > Type = Backup > > Name = vhome_a > > FileSet = "vhome_a_fileset" > > Level = Incremental > > schedule = "homedir-1-schedule" > > Pool = Disk-granite1 > > Storage = granite1-sd-disk > > Messages = Standard > > Priority = 10 > > Spool Data = yes > > Spool Attributes = yes > > Accurate = yes > > Write Bootstrap = "/var/lib/bacula/%c.bsr" > > Client = granite1-fd > > Maximum Concurrent Jobs = 1 > > > > #I might consider using the following, especially if I had > similar > > "Spool Data" parameters by job type: > > #Full Backup Pool = Tape-Pool-1 > > #Differential Backup Pool = Tape-Pool-1 > > } > > > > > > Schedule { > > Name = "homedir-1-schedule" > > > > Run = Level=Full Pool=Tape-Pool-1 SpoolData=yes 1st > mon at > > 01:00 Jan,Apr,Jul,Oct > > Run = Level=Differential Pool=Tape-Pool-1 SpoolData=yes 1st > mon at > > 01:00 Feb,Mar,May,Jun,Aug,Sep,Nov,Dec > > Run = Level=Incremental SpoolData=no 2nd-5th > mon > > at 01:00 #no pool specified, will come from Job/JobDefs > > } > > -- > Lloyd Brown > HPC Systems Administrator > Office of Research Computing > Brigham Young University > http://rc.byu.edu > > > > _______________________________________________ > Bacula-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/bacula-users > -- Lloyd Brown HPC Systems Administrator Office of Research Computing Brigham Young University http://rc.byu.edu --------------7mPRxOqBeav0Owy1HTbUppEC Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <!DOCTYPE html><html><head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body> <p>Yeah. That's the problem. I have enough disk to store the incrementals for the duration we want to, but not the fulls/differentials. That's the problem.<br> <br> I did consider having a "run after job" script that detects whether the job is a full/differential, and is on a disk pool, and immediately scheduling a migration to tape. I'm still not sure I have enough space for that, but at least it would get it off the disks ASAP.<br> <br> I can confirm that having the `spooldata=yes/no` does seem to work on the `run` lines in the schedule. It may depend on the release, but I'm running 15.0.3. My concern is less about that, and more about what happens when something breaks, eg. a full fails, and the subsequent incremental is upgraded automatically.</p> <p>Lloyd</p> <p><br> </p> <div class="moz-cite-prefix">On 7/14/26 10:43, Rob Gerber wrote:<br> </div> <blockquote type="cite" cite="mid:CAMKi9mQt5t0L19nUjv-zCipjUaL-JCGz77DjFmOEtWg_LVjY3g@mail.gmail.com"> <div dir="auto"> <div>I wonder if spooldata = yes/no or a joddef resource can be given as a parameter for a schedule line. Not sure. I don't have the bacula manuals in front of me. </div> <div dir="auto"><br> </div> <div dir="auto">Otherwise, if you have suitable disk space, you could write your full and diff backups to disk, then copy or migrate them off to tape. Spool data would be set off for the disk jobs, and set on for the copy/migrate jobs. Migrate would be the strategy that frees disk space as soon as possible, if you have enough disk to hold one round of fulls, but not enough for all the fulls in your catalog. </div> <div dir="auto"><br> </div> <div dir="auto"><br> </div> <div data-smartmail="gmail_signature">Robert Gerber<br> 402-237-8692<br> <a href="mailto:[email protected]" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a></div> </div> <br> <div class="gmail_quote gmail_quote_container"> <div dir="ltr" class="gmail_attr">On Tue, Jul 14, 2026, 11:33 AM Lloyd Brown <<a href="mailto:[email protected]" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>> wrote:<br> </div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi, all.<br> <br> With my new Bacula 15 deployment, I'm running into something I'd like to <br> do, but I don't think there's a feature for it yet. But before I submit <br> a feature request, I wanted to sanity check, and see if anyone had an <br> alternative that I hadn't considered.<br> <br> Here's the deal. I have jobs that run Full, Differential and <br> Incremental jobs. The Full and Differential jobs are supposed to go to <br> a tape pool, and should use data spooling. The Incremental jobs are <br> supposed to go to a disk pool, and should not use data spooling. The <br> job can have "Full Backup Pool", "Differential Backup Pool", etc., <br> defined, so different job types can end up in different pools. But <br> there's no similar job-type-specific "Spool Data" attribute, is there?<br> <br> Right now, I can handle this by putting in parameters in the Schedule's <br> "run" lines. And if those jobs are successful, then great. But if not <br> (eg. a Full has failed), then subsequent Incremental jobs might get <br> upgraded to be a Full. If I have the "Full Backup Pool" specified, that <br> upgraded job would (I assume) end up in the right pool, but wouldn't <br> have the correct spooling set up. Or if I don't have the "Full Backup <br> Pool" set, then it will end up in the disk pool, instead of the tape <br> pool, albeit with the appropriate spool behavior for the disk pool.<br> <br> I'll put an example of one of my jobs below, so you can tell me what I <br> might be missing. Or I can explain again, if this isn't clear.<br> <br> <br> Thanks,<br> <br> Lloyd<br> <br> <br> <br> Example job:<br> <br> > Job {<br> > Type = Backup<br> > Name = vhome_a<br> > FileSet = "vhome_a_fileset"<br> > Level = Incremental<br> > schedule = "homedir-1-schedule"<br> > Pool = Disk-granite1<br> > Storage = granite1-sd-disk<br> > Messages = Standard<br> > Priority = 10<br> > Spool Data = yes<br> > Spool Attributes = yes<br> > Accurate = yes<br> > Write Bootstrap = "/var/lib/bacula/%c.bsr"<br> > Client = granite1-fd<br> > Maximum Concurrent Jobs = 1<br> ><br> > #I might consider using the following, especially if I had similar <br> > "Spool Data" parameters by job type:<br> > #Full Backup Pool = Tape-Pool-1<br> > #Differential Backup Pool = Tape-Pool-1<br> > }<br> ><br> ><br> > Schedule {<br> > Name = "homedir-1-schedule"<br> ><br> > Run = Level=Full Pool=Tape-Pool-1 SpoolData=yes 1st mon at <br> > 01:00 Jan,Apr,Jul,Oct<br> > Run = Level=Differential Pool=Tape-Pool-1 SpoolData=yes 1st mon at <br> > 01:00 Feb,Mar,May,Jun,Aug,Sep,Nov,Dec<br> > Run = Level=Incremental SpoolData=no 2nd-5th mon <br> > at 01:00 #no pool specified, will come from Job/JobDefs<br> > }<br> <br> -- <br> Lloyd Brown<br> HPC Systems Administrator<br> Office of Research Computing<br> Brigham Young University<br> <a href="http://rc.byu.edu" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">http://rc.byu.edu</a><br> <br> <br> <br> _______________________________________________<br> Bacula-users mailing list<br> <a href="mailto:[email protected]" target="_blank" rel="noreferrer" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a><br> <a href="https://lists.sourceforge.net/lists/listinfo/bacula-users" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://lists.sourceforge.net/lists/listinfo/bacula-users</a><br> </blockquote> </div> </blockquote> <pre class="moz-signature" cols="72">-- Lloyd Brown HPC Systems Administrator Office of Research Computing Brigham Young University <a class="moz-txt-link-freetext" href="http://rc.byu.edu">http://rc.byu.edu</a></pre> </body> </html> --------------7mPRxOqBeav0Owy1HTbUppEC-- --===============2977807227839891614== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============2977807227839891614== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Bacula-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-users --===============2977807227839891614==--