I just wanted to add that my similar problem was also related to network
gear (hardware firewall). I resolved it by following the document below:
http://wiki.bacula.org/doku.php?id=faq#my_backup_starts_but_dies_after_a_while_with_connection_reset_by_peer_error
I did have Heartbeat Interval set s
Le 13/06/2011 14:32, Josh Fisher a écrit :
> On 6/13/2011 2:15 AM, Mike Seda wrote:
>> I forgot to mention that during my debugging, I did have "Heartbeat
>> Interval" set to 10 on the Client, Storage, and Director resources.
>> The same error still occurred... Very odd.
>>
>
> I have encountered s
Le 11/06/2011 11:15, Bruno Friedmann a écrit :
> On 05/20/2011 10:22 AM, Yann Cézard wrote:
>> Hi everyone,
>>
>> Since a few weeks, I am facing a really strange problem with
>> my win32 bacula-fd.
>>
>> [...]
>> - after upgrading the DIR/SD from 5.0.2 to 5.0.3 (Debian squeeze =>
>> wheezy) :
>>
>>
On 6/13/2011 2:15 AM, Mike Seda wrote:
I forgot to mention that during my debugging, I did have "Heartbeat
Interval" set to 10 on the Client, Storage, and Director resources.
The same error still occurred... Very odd.
I have encountered similar situations with clients. Everything but
Bacula
I forgot to mention that during my debugging, I did have "Heartbeat
Interval" set to 10 on the Client, Storage, and Director resources. The
same error still occurred... Very odd.
On 06/10/2011 07:02 PM, Blake Dunlap wrote:
$20 you have the other bacula comm channel failing due to timeout of
t
On 05/20/2011 10:22 AM, Yann Cézard wrote:
> Hi everyone,
>
> Since a few weeks, I am facing a really strange problem with
> my win32 bacula-fd.
>
> It seems that the problem started when I upgraded my SD + DIR
> to the 5.0.X (I was still using the 2.4.4 until that time).
> The problem is that al
$20 you have the other bacula comm channel failing due to timeout of the
state on a forwarding device. Dropping spool sizes is only increasing the
frequency of communication across that path. You will likely see this
problem solved completely by setting a short duration keepalive in your
bacula con
I just encountered a similar error in RHEL 6 using 5.0.3 (on the server
and client) with Data Spooling enabled:
10-Jun 02:06 srv084 JobId 43: Error: bsock.c:393 Write error sending
65536 bytes to Storage daemon:srv010.nowhere.us:9103: ERR=Broken pipe
10-Jun 02:06 srv084 JobId 43: Fatal error: bac
Le 07/06/2011 18:10, Josh Fisher a écrit :
> Another problem I see with Windows 7 clients is too aggressive power
> management turning off the Ethernet interface even though it is in use
> by bacula-fd. Apparently there is some Windows system call that a
> service (daemon) must make to tell Wind
On 6/7/2011 5:40 AM, Yann Cézard wrote:
> Le 06/06/2011 19:56, Josh Fisher a écrit :
>> Try setting "Maximum Network Buffer Size" to 32768 in both the storage
>> daemon and client configs. It looks like something doesn't like the
>> default 65536 buffer size.
>>
>> Also, a backup job can run a lon
Le 06/06/2011 19:56, Josh Fisher a écrit :
> Try setting "Maximum Network Buffer Size" to 32768 in both the storage
> daemon and client configs. It looks like something doesn't like the
> default 65536 buffer size.
>
> Also, a backup job can run a long time, and Bacula keeps the TCP
> connection
On 6/6/2011 12:46 PM, Yann Cézard wrote:
> Le 20/05/2011 10:22, Yann Cézard a écrit :
>> Hi everyone,
>>
>> Since a few weeks, I am facing a really strange problem with
>> my win32 bacula-fd.
>>
>> It seems that the problem started when I upgraded my SD + DIR
>> to the 5.0.X (I was still using the
Le 20/05/2011 10:22, Yann Cézard a écrit :
> Hi everyone,
>
> Since a few weeks, I am facing a really strange problem with
> my win32 bacula-fd.
>
> It seems that the problem started when I upgraded my SD + DIR
> to the 5.0.X (I was still using the 2.4.4 until that time).
> The problem is that almo
13 matches
Mail list logo
