Am 20.09.2017 um 13:47 schrieb Josh Fisher: > > Yes. Job attributes, file metadata, etc. that is to be stored in the db, > are spooled to a file in /var/spool/bacula while the fd is actively > transmitting data. After data transmission is complete (or if the spool > file becomes large enough?), Bacula reads the cached metadata from the > file and updates the db in batch mode. This is used both to speed db > updates and to prevent constant db updates from slowing down collection > of the fd's data..
In OpenBSD it appears to be a binary file named <devicename><jobname><date>.spool. I've found a 55 MB file of the failed backup in /var/bacula, but the current job's spool file is already about 65MB and counting. > Because Bacula expects TCP connections to remain connected throughout > the job. If for some reason the connection is dropped by the fd, or by a > router or switch in between the fd and dir, then it is seen by dir as a > dropped connection. There are several ways that the connection might be > dropped; I don't think the connection is dropped at all. Can it be that despooling (=writing to the db) takes too long and bacula considers the connection broken? That would be a odd behaviour. Btw I was getting plenty of connection errors before I raised the Heartbeat Interval directive. They looked different. Matthias ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
