Thanks for all the replies folks...
I've tried a few things, and I think I may have found the problem... although
I've onyl had time to kick off 2 scheduled jobs since the fix, so it's not been
tested to destruction...
The bacula server is called 'viper'. viper is a hyper-v VM sitting on the ho
Hi All,
I have, what I think, Is a fairly obscure bacula issue.
my bacula-dir server is a CentOS 5.5 server, running as a VM on MS Hyper-V, on
a windows 2008R2 host. I'm managed to successfully backup a number of windows
servers, and I'm happy that all the client-fd stuff is setup correctly.
h
Happyness comes in bconsole messages!
I finally figured out the problem, and am posting the solution here incase
anyone else has the same issue in the future.
I had made sure I disabled the windows firewall on the client machine. I
thought I'd also done iptables -F on the bacula server as wel
The job I started earlier has now finished, so I can give you the output of the
log file
The error states that I can't connect to the SD on viper (the backup server).
If I'm correct in thinking that it's the SD that manage the writing of the
backup to disk/tape, then this will explain why no fi
A small update:
I realised that tha viper-fd password complaint was related to the viper-fd
password which was set up in bacula-dir.conf. I change that this morning,
cleared out the db, and tried running the job again from bconsole.
We have now gotten rid of the auth error, but it does not seem
Hi All,
First off, I should mention that I have spent days trawling the internet for
answers, including right here at backup central. I have managed to fix many of
the issue I'd been having along the way, but now... now I've really hit a brick
wall.
so, I'm fairly new to *nix of any flavour, b
