Grant wrote:
> I am using a laptop over a wireless connection that I am trying to
> backup through Bacula. I do have Bacula working and backing up two
> other Linux machines as well as one other Windows machine. All are on
> Ethernet however.
>
> On this laptop, I have 3 jobs setup. Two wor
* Martin Simmons schrieb am 07.10.08 um 13:23 Uhr:
> > On Tue, 7 Oct 2008 07:37:36 +0200, Kern Sibbald said:
> >
> >
> > I personally don't find it that confusing, but am willing to admit that
> > some
> > would. So, what is the solution?
> >
> > Drop the feature?
> >
> > Change the f
is there a document that outlines the steps necessary to purge 'older' data on
a disk device that is
full? i understand that my retention levels are not correct, but i wish to
purge data at my
discression until i get it all figured out.
regards,
_Terry
--
* Martin Simmons schrieb am 07.10.08 um 13:00 Uhr:
> >
> > I voted for putting it into the Exclude section because this
> > directive is about *excluding* directories from the backup.
>
> True, but...
>
> > So if
> > someone uses this d
>> 30-Sep 01:06 bacula-sd JobId 227: Error: block.c:275 Volume data error
>> at 0:1! Wanted ID: "BB02", got "". Buffer discarded.
I believe this means the tape was overwritten or corrupted for some
reason. Since the first block does not have a valid header on it
bacula is not able to go any furth
bacula schrieb:
> Hi,
>
> i have 3 Jobs running nightly. Every job has verify-job. One job isnt
> verifying right. I got this error:
>
> 30-Sep 01:05 bacula-dir JobId 227: Verifying against JobId=223
> Job=Datev-Tape.2008-09-29_23.05.00
> 30-Sep 01:05 bacula-dir JobId 227: Bootstrap records writte
> Hi,
>
> Always when I do a restore the next backup causes this error. I
> already added
>
> tape-config-list=
> "EXABYTE VXA-2", "Exabyte VXA-2", "VXA-2";
> VXA-2 = 1,0x36,0,0x19e39,2,0x80,0x81,1;
>
> to the Solaris 10 file /kernel/drv/st.conf to fix a problem when the
> end of tape is rea
> On Tue, 7 Oct 2008 07:37:36 +0200, Kern Sibbald said:
>
> On Monday 06 October 2008 22:04:39 Martin Simmons wrote:
> > > On Mon, 6 Oct 2008 13:05:49 +0200, Kern Sibbald said:
> > >
> > > On Monday 06 October 2008 06:22:51 Troy Daniels wrote:
> > > > Hi,
> > > >
> > > > Not sure if this h
> On Tue, 7 Oct 2008 00:59:48 +0200, Marc Schiffbauer said:
> Mail-Followup-To: [EMAIL PROTECTED],
>
> * Martin Simmons schrieb am 06.10.08 um 22:04 Uhr:
> >
> > If it hasn't been done already, it could be useful to consider how this
> > affects the mental model that users have of the include
Hi Marc,
i had to upgrade Ver. 1.38 didn't work, btw the bacula-fd is still an old
version.
My Director is now 2.4.2 and it works, i have successfully excluded all SVN and
CVS Working Copys.
THX for your Help
--
Mit freundlichen Grüßen aus Aachen
i.A. Boris Kunstleben
Administration
-
Arno Lehmann schrieb:
> Perhaps a hardware-related problem? Have you had a look into the
> system's log files?
Didn't find anything related in the logs.
> > Then the sd died:
>
> Now that's bad... even in case of a seriuos problem the SD shouldn't die.
>
> > 07-Okt 00:19 VU0EA003-sd: ABORTI
Hi,
07.10.2008 09:54, Ralf Gross wrote:
> Hi,
>
> last night I was hit by a mtx/drive problem.
>
> 20081007-00:02:22 Doing mtx -f /dev/Neo4100 load 96 2
> 20081007-00:02:22 Device /dev/ULTRIUM-TD4-D3 - not ready, retrying...
> 20081007-00:02:23 Device /dev/ULTRIUM-TD4-D3
And now the Director lives every morning!
Thanks. I did 2 things different, one/both might have fixed it. First I did as
you suggested and left it with no jobs in this wierd R state. Next I thought
back to the last thing I changed and I was actually trying to get the emails
sent to a different a
Hi,
last night I was hit by a mtx/drive problem.
20081007-00:02:22 Doing mtx -f /dev/Neo4100 load 96 2
20081007-00:02:22 Device /dev/ULTRIUM-TD4-D3 - not ready, retrying...
20081007-00:02:23 Device /dev/ULTRIUM-TD4-D3 - not ready, retrying...
[...]
20081007-00:07:35 Parms: /dev/Neo4100 loaded
terryc wrote:
> Ronald Buder wrote:
>
>
>> Just a few thoughts from us. Opinions welcome, maybe we are just
>> approaching this entirely wrong. However the environment here looks
>> somewhat like the scenario described above. We run plenty of Windows
>> Server boxes, Solaris and Linux, and fo
15 matches
Mail list logo
