On 6/13/24 08:13, Gary R. Schmidt wrote:
On 13/06/2024 20:12, Stefan G. Weichinger wrote:
interested as well, I need to speedup my weekly/monthly FULL runs
(with LTO6, though: way slower anyway).
Shouldn't the file daemon do multiple jobs in parallel?
To tape you can only write ONE stream of data.
To the spooling disk there could be more than one stream.
Yes, that seems wrong:
$ grep Concurrent *.conf
bacula-dir.conf: Maximum Concurrent Jobs = 50
bacula-dir.conf: Maximum Concurrent Jobs = 50
bacula-fd.conf: Maximum Concurrent Jobs = 50
bacula-sd.conf: Maximum Concurrent Jobs = 50
Sorry, I still don't understand what to adjust ;-)
that interleaving to tape sounds dangerous to me.
That's how Bacula works - and has since day one.
We've been using it like that since 2009, starting with an LTO-4
autoloader, currently using an LTO-6, and I'm about to start agitating
to upgrade to LTO-9.
Interleaving is not really an issue when data spooling is enabled. Data
is despooled to tape one job at a time. Only when the spool size is too
small will there be any interleaving. Even then, the interleaving will
be a whole bunch of one job's blocks followed by a whole bunch of
another. I't not a problem, and with sufficient disk space for the
spool, it doesn't even happen.
What I want to have: the fd(s) should be able to dump backups to the
spooling directory WHILE in parallel the sd spools previous backup
jobs from spooling directory to tape (assuming I have only one tape
drive, which is the case)
Bacula does not work that way. No doubt if you tried really hard with
priority and concurrency and pools you could maybe make it work like
that, but just RTFM and use it as designed.
Why not? According to
https://www.bacula.org/15.0.x-manuals/en/main/Data_Spooling.html it
works exactly that way already. Most importantly, concurrent jobs
continue to spool while one job is despooling to tape. Only one job is
ever despooling at a given time.
On the other hand, the job that is despooling has exclusive control of
the tape drive. On the last despool for a job (there ma be more than one
if the job data exceeds the maximum spool size), the job has to also
despool the job's spooled attributes to the catalog database before it
releases the tape drive. Thus, even when other concurrent jobs are
waiting to be despooled, the tape drive will be idle (or at least
writing from its internal buffer) while the database writes occur. This
is one of the reasons that database performance is so important in
Bacula. I believe that the attributes are despooled before releasing the
tape drive in order to ensure that despooling of both data and
attributes is an atomic operation at job completion, probably to avoid
race conditions.
-> parallelizing things more
It all seems quite parallel to me.
Cheers,
Gary B-)
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
