On Sun, 19 Apr 2009, John Drescher wrote:
> > But seriously, you're not going to tell me that the bacula-dir process is
> > going to need 2.6 GB of memory because of a few messages?
> >
> When I replied I did think of that. That is quite excessive, I was
> thinking thousands of messages but enough
On Sun, 19 Apr 2009, John Drescher wrote:
> Well 2 drives are blocked because you have no appendable or usable
> media. Any idea on how long it has been waiting for you to add tapes?
> Perhaps the memory problem is that the messages are growing. Have you
> typed messages in bconsole recently?
Jus
On Sat, 18 Apr 2009, Dan Langille wrote:
> I no longer see the original detail, but I suspect there is one job
> running, and it has spooled attributes waiting to be written. That is y
> theory.
Running Jobs:
Writing: Incremental Backup job analytics.2009-04-11_23 JobId=1229
Volume=""
pool=
On Thu, 16 Apr 2009, Dan Langille wrote:
> > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
> > 1264 root 15 0 2007m 804m 1408 S 0.0 78.6 2:49.23 bacula-dir
> >
> > http://filepile.dicp.de/bacula-dir-memory.png
>
> Could this be the spooled attributes taking up m
We have a bacula-dir system which is waiting for manual intervention for
some days time now. Due to technical problems with the tape drive, the
problem will be with us for a few more days.
Memory consumption of the bacula-dir process is rather high though
according to top:
PID USER PR
Hi,
I'm seeing a rather surprising message during the fill test in btape about
writing an EOF on a tape failing: "dev.c:1662 Attempt to WEOF on
non-appendable Volume"
This message is being generated during the fill test of btape,
specifically after the tape has been changed by the mtx-changer
Hi,
I happen to have a strange problem here with a bacula-client running on a
x86_64 host. The incremental backups are nearly the same size as the full
backup even though not many files changed.
The host is a webserver which was running on a IA32 host before with a
nighty incremental backup siz
Hi,
I just installed the bacula 1.36.2 on one of our servers, which is
connecting to a director and storage deamon both running 1.34.6.
When trying to run a backup I'm getting the following message about bacula
not being able to get the ACLs of (it seems) every file on the
disc:
bender-dir: C
On Tue, 12 Apr 2005, Andreas Thienemann wrote:
> Sure, I couldn't find anything there suggesting incompatibilities. The
> only thing I found was a reference to Tim's ACL patch, what ever that may
> be.
but even with the 1.36.2 version installed I'm getting the same error
Hello,
On Tue, 12 Apr 2005, Arno Lehmann wrote:
[Error tryingto get ACL from...]
> There are / were difficulties there... I don't know the deatils, but you
> might search the mailinglist archives (both users and devel) and the
> bugs database at bugs.bacula.org
Hmm. I looked, but I haven't seen
10 matches
Mail list logo
