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
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 almost (this is only observable on Full backups
of several GB
14 matches
Mail list logo