In message <[EMAIL PROTECTED]> you wrote:
> However, much of the reason you'd want to spool is to limit the amount
> of time that the client system is affected by a backup. Unless I'm
> mistaken -- which is quite possible -- the machine spools much more
> quickly than it would be able to write to tape, and then the RunAfterJob
> script can run much sooner. Is that actually true?
This is only true if your spool file is big enough to hold whe
*whole* backup at once. Otherwise you will see a repeated sequence of
Spooling data ...
User specified spool size reached.
Writing spooled data to Volume. Despooling XXX bytes ...
Spooling data again ...
User specified spool size reached.
Writing spooled data to Volume. Despooling XXX bytes ...
...
and the client system is affected for a much longer time.
And assuming you are backing up some big RAID array it might be
difficult to provide big enough spool files.
So the only real advantage of data spooling as I see it is that it
helps to reduce tape (drive) wear by avoiding frequent start-stop
sequences - which is only a problem if your file system cannot
provide the data faster than the tape can write. In my experience
this is only the case for differential and incremental backups - and
then the data size might be small enough to fit in a spool file.
Ideally I'd like to be able to turn spooling off for level "full"
backups while leaving it tuirned on for "differential" and
"incremental" ones.
I didn't find out yet how to do this. Any pointers?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
The speed of time is one second per second.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
