Am 29.12.2017 um 15:07 schrieb Dan Langille:
>> JobId 21: BeforeJob: could not identify current directory:
>> Permission denied
>> JobId 21: BeforeJob: could not identify current directory:
>> Permission denied
>> JobId 21: BeforeJob: psql: could not find own program executable
>> JobId 21: Be
Good morning everybody,
a fresh installation of 9.0.4 on OpenBSD 6.2 is giving me various
troubles. Amoong other things, the catalog backups fail:
From bacula.log:
JobId 21: BeforeJob: could not identify current directory:
Permission denied
JobId 21: BeforeJob: could not identify current dire
I have added a new client into my configuration, but backup jobs are
failing, although the director apparently connets.
Here's a sample error message:
Error: getmsg.c:185 Malformed message: Jmsg JobId=3250 type=3
level=1513162330 mimir.syspac.ads JobId 3250: Fatal error: backup.c:826
Network sen
Am 20.09.2017 um 15:38 schrieb Phil Stracchino:
> I'm curious — what back-end DB are you using?
It's PostgreSQL 9.5.3.
Matthias
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slash
Am 20.09.2017 um 13:47 schrieb Josh Fisher:
>
> Yes. Job attributes, file metadata, etc. that is to be stored in the db,
> are spooled to a file in /var/spool/bacula while the fd is actively
> transmitting data. After data transmission is complete (or if the spool
> file becomes large enough?), Ba
Am 19.09.2017 um 15:46 schrieb Can Şirin:
> My jobs have almost 30M
> files x 8 parallell jobs, and it takes about 20 hours to despool
> attributes.
So you are saying that the whole backup run times out because the
database is taking so long? From what I could see with "top", the DB
never create
>> Standard-Device Elapsed time=25:57:52, Transfer rate=1.463 M Bytes/second
>> Sending spooled attrs to the Director. Despooling 431,639,287 bytes ...
And this is how it ended - again, after five or so more hours:
Fatal error: Network error with FD during Backup:
ERR=Connection reset by peer
After a long and apparently successful backup job, I am getting this:
Standard-Device Elapsed time=25:57:52, Transfer rate=1.463 M Bytes/second
Sending spooled attrs to the Director. Despooling 431,639,287 bytes ...
It's been about an hour now that the job stopped writing to the volume.
The job
Am 07.09.2017 um 11:04 schrieb Josip Deanovic:
> On Thursday 2017-09-07 08:50:14 Matthias Koch-Schirrmeister wrote:
>> Am 06.09.2017 um 10:13 schrieb Matthias Koch-Schirrmeister:
>>> Setting both to
>>>
>>> Heartbeat Interval = 600
>>>
>>>
Am 06.09.2017 um 10:13 schrieb Matthias Koch-Schirrmeister:
> Setting both to
>
> Heartbeat Interval = 600
>
> now.
First run looks good. I will do more checks. Thank you very much so far,
hope that was the solution. The odd thing is, this used to work for over
a year with
Am 05.09.2017 um 15:57 schrieb Kern Sibbald:
> Very likely the line timed out. You can probably correct the problem by
> setting the HeartBeat Interval. Note, you must set it in quite a few
> places. I recommend not to use anything smaller than 600 (i.e. 5 minutes).
In the given case I understa
Am 04.09.2017 um 14:05 schrieb Heitor Faria:
> Please inform Director, Storage and File Daemon versions.
The versions are
Director: 7.4.2
SD: 7.4.2
both on OpenBSD 6.0
FD: 5.2.6 on Debian 7
Kern has already mentioned concerns about the versions, but I am running
a number of 5.* FDs on Linux
Still having trouble with the monthly full backups on a remote machine.
Through bconsole, the remote machine is telling me the job is finished:
No Jobs running.
Terminated Jobs:
JobId LevelFiles Bytes Status FinishedName
===
Am 21.06.2017 um 16:57 schrieb Kern Sibbald:
At least that would be something to check.
Hi Kern, thanks for the reply. The heartbeat directive is set:
FileDaemon {
...
Heartbeat Interval = 60
}
and
Director {
...
Heartbeat Interval = 60
}
respectively.
While the job in question is b
It is remarkable that the FD reports 15:01 as finishing time, while the
director reported a failure at 18:57. This probably means that the
director waited for almost four hours for something that never happened,
and gave up at 18:57.
Matthias
signature.asc
Description: OpenPGP digital signature
I have managed to keep a long backup running (125GB /23 hours). While
the remote FD reports a success
JobId LevelFiles Bytes Status FinishedName
==
940 Full 1,022,421125.2 G OK 20-Jun-17 15:
I've been running 7.0.5 with MySQL on OpenBSD 5.8, and currently 7.4.2
with PostgreSQL on OpenBSD 6.0. My clients are both Windows (V 5.x) and
Linux machines.
I am currently migrating my core services to OpenBSD because right now
it appears that Linux is going to be systemd as a secondary OS runni
I have put the jobs in question back on the old 7.0.5 director and
they've been running fine over the weekend. I figure it must be
something between the client (5.2.x) and director versions, because all
other parameters, connection and everything, are identical. I wonder if
there's a way to further
And another error:
Fatal error: append.c:183 Error reading data header from FD. n=-2
msglen=0 ERR=Connection reset by peer
Don't know how to read it, though.
This time a CentOS client running FD 5.2.13 is affected.
I have no reasons to believe that we actually lost physical connection
to the re
Am 07.04.2017 um 14:27 schrieb Heitor Faria:
> Having a too old FD (5.2.6) in relation to Director can also result in
problems depending on the Bacula backup settings.
> I'd suggest you upgrading your FD.
That would have been my first pcik. I have actually two remote clients,
both of them an the
Good morning list, here's my setup:
Director 7.4.2 running on OpenBSD 6.0 (hostname "fafnir")
FD 5.2.6 running on Debian/GNU Linux 7.0 on a remote site (hostname
"perseus")
Connected by a TLS tunnel
I have been using this for about a year now, for backing up both on-site
and off-site machines. T
21 matches
Mail list logo
