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
I recompiled bacula with mysql support instead postgresql.
Now it works fine.
Victor Sterpu wrote:
> Backing up a mail server I realized that the backup is incomplete.
> I use bacula 2.4.4.
> Bacula-fd runs as root.
> My FileSet is like this:
> FileSet {
> Name = "mail"
> Include {
>
I run a incremental job, but when I try to restore I should see all the
files.
I did this at the bacula console:
> restore
> 5: Select the most recent backup for a client
Automatically selected FileSet: mail
+---+---+--+-+-+-+
| jobi
I run a incremental job, but when I try to restore I should see all the
files.
I did this at the bacula console:
> restore
> 5: Select the most recent backup for a client
Automatically selected FileSet: mail
+---+---+--+-+-+-+
| jobi
Ralf Gross wrote:
Victor Sterpu schrieb:
Backing up a mail server I realized that the backup is incomplete.
I use bacula 2.4.4.
Bacula-fd runs as root.
My FileSet is like this:
FileSet {
Name = "mail"
Include {
Options {
signature = MD5
compression = GZIP
Victor Sterpu schrieb:
> Backing up a mail server I realized that the backup is incomplete.
> I use bacula 2.4.4.
> Bacula-fd runs as root.
> My FileSet is like this:
> FileSet {
> Name = "mail"
> Include {
> Options {
> signature = MD5
> compression = GZIP
>
I runned bacula in debug mode and found out something strange.
bacula-dir -c /etc/bacula/bacula-dir.conf -d99 -f -u bacula > bacula.out
The command "cat bacula.out | grep postgres" returns this:
192.168.0.191-dir: postgresql.c:194-0 pg_real_connect done
192.168.0.191-dir: postgresql.c:196-0 db_use
I read this link.
http://article.gmane.org/gmane.comp.sysutils.backup.bacula.devel/12074/
I use postgresql, but my database is SQL_ASCII, so it seems that I don't
fit in this bug report.
Victor Sterpu wrote:
> Backing up a mail server I realized that the backup is incomplete.
> I use bacula 2.4.4
17 matches
Mail list logo
