Hi, again!
I hate to return to this but I got the same errors on my other backup
server. Running the same type of copy job! Just minutes ago. This system
is running the same configuration:
Centos 6.9
Linux 2.6.32-696.10.1.el6_x86_64
Mariadb 10.2.8
Bacula 9.0.3
Nothing has changed in the Bacula
Yes, kilchis is a bonifide hardware server. Only VM's I have are test
systems running on my desktop.
There are 2 copy jobs on this system. This particular job is the one that
typically runs long enough that it will need a new volume during the
night. The other one will if it is run late in the da
That's odd -- the reading side looks normal to me until the error is detected.
Also, "Connection reset by peer" doesn't normally occur when connected to the
current machine.
Is kilchis a real computer (not a VM)?
Is this the only copy job that waits overnight for someone to label a new
volume?
The reading side is the same system. It is a copy job setup to backup
daily backups to the offsite backup disk.
The attachment is the bacula jobid 35202.
jerry
On Tue, Sep 19, 2017 at 10:08 AM, Martin Simmons
wrote:
> The email below is from the writing side of the copy job and the message:
>
The email below is from the writing side of the copy job and the message:
13-Sep 08:43 kilchis JobId 35203: Error: bsock.c:849 Read error from Storage
daemon:kilchis:9103: ERR=Connection reset by peer
shows that the connection to the reading side of the job was closed
unexpectedly from the readi
A copy job will communicate using TCP between the Bacula daemons. A bsock
error could indicate that bacula-sd closed the connection unexpectedly and I
would expect media errors to be logged.
Your syslog did include some I/O errors. Any they caused by something else?
Do you have the complete job
No, the only thing that shows in the messages file is that I changed the
disk 3 times as they filled up.
jerry
On Wed, Sep 13, 2017 at 10:51 AM, Josip Deanovic wrote:
> On Wednesday 2017-09-13 09:35:07 Jerry Lowry wrote:
> > Kern,
> > My Offsite Backup just failed again on the same drive, diffe
On Wednesday 2017-09-13 09:35:07 Jerry Lowry wrote:
> Kern,
> My Offsite Backup just failed again on the same drive, different disk.
> It failed with the same bsock error. If the backup is working on the
> same system using the copy function, how far out of the network stack
> does it go. My thin
Kern,
My Offsite Backup just failed again on the same drive, different disk. It
failed with the same bsock error. If the backup is working on the same
system using the copy function, how far out of the network stack does it
go. My thinking is it does not get out of the application layer. Is this
Hello,
If the job is marked as Incomplete in the catalog ("I" I think),
then you can simply restart it and it should pickup where it left
off. If not you must run it again from the beginning.
If you are switching devices when one is full during a Job, it is
unl
List,
I am running, bacula 9.0.3, Mariadb 12.2.8 on Centos 6.9. I got notice
last night that my Offsite backup failed due to a bsock error. My offsite
drives are attached to an ATTO raid card which gives me hot swap
capability. This configuration works great as it allows me to hot swap a
drive wh
11 matches
Mail list logo
