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
_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users
