Some while ago (July 04) there was discussion about extending the
Scheduler to include jobs run every n days/weeks, etc, such as:
Schedule {
Name = "DayWeekMonth"
Run = Full from 2005-01-02 1:00:00 every 4 weeks
Run = Incremental from 2004-01-09 1:00:00 every 4 weeks
Run = Incremen
FWIW
Latest installment in the ongoing saga of Bacula on the Mason County
(Washington) network.
For reasons that quite escape me, Bacula began having trouble with tape drives.
The typical error when I would try to mount a tape on a drive that had
previously had no problems at all was that it f
On Wednesday 29 June 2005 01:22 pm, David Clymer wrote:
> On Mon, 2005-06-27 at 17:09 -0500, Mike Reinehr wrote:
> > On Monday 27 June 2005 04:54 pm, Mike Reinehr wrote:
> > > Oh, oh! I seem to have just shot myself in the foot!
> > >
> > > I edited /etc/bacula/bacula-dir.conf to add the necessary
I just set this up and am generally having success. I do find that
label commands seem to hang mysteriously from time to time. I am still
coming up to speed with having a virtual autochanger now ...
Question - are you running bacula-sd as root?
Jay
On 1-Jul-05, at 4:36 PM, Richard White wrote
OK. After reading the comments in the multitape-changer script in greater
detail, I made this change to the bacula-sd.conf:
Changer Command = "/etc/bacula/scripts/multitape-changer /dev/null load 1
/dev/nst1 0"
One more item that I overlooked in last msg.
The multitape-changer script has a line referring to the label directory
(/etc/bacula/tapelabel). I created this directory, but I don't know what to put
there. It may be important, since the script referes to label files a short way
down from there.
Thanks to all for the tips on spanning tapes/drives. I have attempted to
implement Mario Wolff's solution (archives, Jan. 28 & 29). Bacula loads, but
can't recognize the multitape drive. Here are the critical sections:
bacula-sd.conf
.
.
.
# Multi-tape drive
Device {
Name = Multitape
Media Typ
On Fri, Jul 01, 2005 at 02:47:30PM +0200, Xavier Romero wrote:
>
> I've updated from 1.36.1 to 1.36.3. Certainly that was a display bug
> about the IP addres.
> With the right IP address being logged i realized than the cause of
> these annoying messages was our Nagios box doing check_tcp against
On Friday 01 July 2005 14:47, Xavier Romero wrote:
> I've updated from 1.36.1 to 1.36.3. Certainly that was a display bug
> about the IP addres.
> With the right IP address being logged i realized than the cause of
> these annoying messages was our Nagios box doing check_tcp against the
> bacula se
I've updated from 1.36.1 to 1.36.3. Certainly that was a display bug
about the IP addres.
With the right IP address being logged i realized than the cause of
these annoying messages was our Nagios box doing check_tcp against the
bacula server :-/
I will find out a better way to determine if Bacula
Hi!
I've experienced a problem where the storage daemon did automatically
label a new tape for an already cancelled job.
I'll try to outline my problem:
A few days ago, the director tried to automatically create a new volume
for my daily pool, because the pool didn't contain any acceptable v
11 matches
Mail list logo
