About this issue!
I've had this behaviour sometimes in a Verify Job Level Data.
Best regards
*Wanderlei Hüttel*
http://www.bacula.com.br
Em qua, 20 de fev de 2019 às 10:06, William Muriithi
escreveu:
> Hello Simmons,
>
>
> > Unless something like Samba is converting the symlink to a
Hello Simmons,
> Unless something like Samba is converting the symlink to a directory, Bacula
will not follow it.
Okay, that is great to know.
> Filling /tmp might cause the problem, but it should really fail with an error.
Really wish that is the case but that is the only thing that make
Unless something like Samba is converting the symlink to a directory, Bacula
will not follow it.
Filling /tmp might cause the problem, but it should really fail with an error.
According to the "stat client" output, it has written 3.3 TB so far. If your
data is reasonably compressible then that
Hello,
pon., 18 lut 2019 o 17:27 Martin Simmons napisał(a):
> > On Fri, 15 Feb 2019 15:21:16 +, William Muriithi said:
> >
> > > Also, try "status dir" to see what the Director is doing.
> >
> > Hmm, this see to help. I believe this is the job number 7 that has a
> fatal error as
Hi all,
Thanks all for the feedback. The file path was actually a symlinc that I think
I had created in a weird way, ended up being recursive. I used unlink to dump
it on both the source and backups server. The backup never progressed
I suspect I may have found the root cause though. I
> On Fri, 15 Feb 2019 15:10:13 +, William Muriithi said:
>
> > have you tried the "stat client" command? If you run it a few times you
> > should be able to spot if there's still data transfer activity.
>
> Daemon started 12-Feb-19 11:53. Jobs: run=4 running=0.
> Heap: heap=135,168
> On Fri, 15 Feb 2019 15:21:16 +, William Muriithi said:
>
> > Also, try "status dir" to see what the Director is doing.
>
> Hmm, this see to help. I believe this is the job number 7 that has a fatal
> error as status. Wish it was more elaborate than that. Have you seen that
>
Am 15.02.2019 um 16:10 schrieb William Muriithi:
>> have you tried the "stat client" command? If you run it a few times you
>> should be able to spot if there's still data transfer activity.
>
> Daemon started 12-Feb-19 11:53. Jobs: run=4 running=0.
> Heap: heap=135,168 smbytes=586,060
Hi Uwe,
> have you tried the "stat client" command? If you run it a few times you
> should be able to spot if there's still data transfer activity.
Daemon started 12-Feb-19 11:53. Jobs: run=4 running=0.
Heap: heap=135,168 smbytes=586,060 max_bytes=639,633 bufs=465 max_bufs=515
Sizeof:
Hi Martin,
Thanks a lot for your response.
> Is the log really "nothing"? It should at least show the last thing that
> happened.
Honestly nothing, the last 3 lines on bacula.log was on 12-Feb 15:58 and that
was before I started the pending backup job
> Also, try "status dir" to see what
> On Thu, 14 Feb 2019 16:49:40 +, William Muriithi said:
>
> That hasn't changed for the last 5 hours. The director, storage and client
> are all fine and responsive to console, but no activity. Nothing on the
> director's log too.
>
> So the question is, how would one go around
On Thu, Feb 14, 2019 at 04:49:40PM +, William Muriithi wrote:
> Hello,
>
> I have a new bacula setup and for the last two day, has been running the
> first large scheduled job. Sometimes early this morning, it looks like
> bacula stopped writing to the tape
>
> I was monitoring it using
12 matches
Mail list logo
