Hi,
19.07.2008 11:13, Bernard Grymonpon wrote:
> Hi all,
>
> We experience a strange problem when running backup-jobs on one of our
> windows machines (client is windows, server is linux, debian + bacula
> 2.4.1). We backup multiple windows machines with this setup, and all
> others run fine.
>
> The sympthoms:
>
> When starting a backup, everything goes fine. The job starts running,
> on the windows I see a VSS snapshot being created (vssadmin list
> shadows), and files come in. Once "done", this is the result:
>
> st dir output:
>
> Running Jobs:
> JobId Level Name Status
> ======================================================================
> 2289 Increme srv07-bru.2008-07-19_10.03.03 is running
> ====
>
> st storage output:
>
> Terminated Jobs:
> JobId Level Files Bytes Status Finished Name
> ===================================================================
> ....(snip)...
> 2289 Incr 12,237 3.029 G OK 19-Jul-08 10:17 srv07-bru
> ====
>
> st client output:
>
> Running Jobs:
> Director connected at: 19-Jul-08 11:07
> No Jobs running.
> ====
>
> Terminated Jobs:
> JobId Level Files Bytes Status Finished Name
> ======================================================================
> ....(snip)....
> 2289 Incr 12,237 3.026 G OK 19-Jul-08 10:17 srv07-bru
> ====
>
> So, both the SD and the FD indicate the job as done; and somehow, the
> job does not end. Other jobs on the server finish normally, so nothing
> seems wrong with the server setup. If we wait a while, the job
> terminates eventually, but in an error state, and the backup job is
> marked as faulty. A bls shows the files in the volume. The VSS
> snapshot no longer exists on the client.
>
> We tried a NTBackup on the machine itself, to rule out errors in the
> VSS drivers on the machine. This backup runs fine, and generates no
> errors. Nothing shows up in the event log,..
>
> Does anyone have some idea's how I could debug this further? Can I get
> info on the running job, so I could know what it is waiting for? Any
> other angles how I can try to fix this?
You could debug this by using 'setdebug level=<debuglevel> trace=1
client=<client-fd>' in bconsole. This will generate a debug trace file
in the FD's working directory. You can see what it's doing in that file.
A good start for the debug level is 100. Higher levels create more
information, but also hardly readable trace files :-)
As to possible origins of the problem, it might be network related,
like the DIR-FD connection being cut, so the FD can't report its
status back.
Investigate firewalls and routers in between, and try to set a
"Heartbeat Interval".
Arno
> Rgds,
> Bernard
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Bacula-users mailing list
> Bacula-users AT lists.sourceforge DOT net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
>
--
Arno Lehmann
IT-Service Lehmann
www.its-lehmann.de
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
