Ntbackup seems not to start properly 30 to 50% of the time.


I have a simple script running from scheduler. The script runs as
expected, however, the ntback command in it does not always run
properly.

When it fails to run the log file is always empty and has a time stamp
33 minutes after the start of the script. Also when it fails there are
no entries for ntback in the event log.

This happens on two separate Win2003 R2 server machines.

There is a mention in technet that someone being logged in can cause
random failures. In the case of these machines no-one is logged in and
it is almost every other run that fails.

Anyone any ideas?

Don C


=====
Script:


echo %date% %time% Start of B02 >> D:\ServerBackups\BKlog.log
echo User=%UserName%, Path=%path% >> D:\ServerBackups\BKlog.log

ntbackup backup "@D:\ServerBackups\CFP-BK01.bks" /m normal /P "4mm DDS"
-j "CFPBackup" -d "CFPBackup" /v:yes /r:no /l:s /rs:no /SNAPff /um

echo %date% %time% End of B02 >> D:\ServerBackups\BKlog.log

=====
Log:

10/04/2008 19:30:00.23 Start of B02
User=Administrator,
Path=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\Sys tem32\Wbem;C:\Program
Files\Intel\DMIX;C:\Program Files\Gemplus\GemSafe Libraries\Bin;
10/04/2008 20:03:02.37 End of B02

"Donald Campbell" <Donald@suedon.co.uk> wrote in message
news:1NHZmTBfno$HFAIP@suedonltd.demon.co.uk...
Since this happens quite often, you should try and watch what
happens. Set the scheduled backup time to some reasonable
hour, then start a console session a few minutes before the
scheduled start time, making sure to log on under the same
account as the one used for the scheduled job.

This is a frequent subject in this newsgroup and your feedback
would be appreciated.

In article <uQ3z#pHnIHA.1204@TK2MSFTNGP03.phx.gbl>, "Pegasus (MVP)"
<I.can@fly.com.oz> writes
Just been away for 5 days holidays, during which time the backups on the
two servers failed.

Each night the script ran as a scheduled task, but the ntbackup routine
itself did not. Again it just seems to think about running for 33
minutes and then exits. However, there is no entry in the event log.

Last night I RDC into each server in turn and waited. Both backups ran
without any problems!

Don C

In article <ofW9$xAN+ZCIFAu4@suedonltd.demon.co.uk>, Donald Campbell
<Donald@suedon.co.uk> writes
I built a small test server and using AT instead of Windows Scheduler, I
had the script successfully run 6 backups per day for the last three
days.

However, in the live environment it still failed, again with this
strange 33 minutes in which ntback does not start properly.

Today I re-booted both live servers and this evening the backups are
running!

Dare I breath? I am sure that one could die of frustration.


Don C

In article <R0EAY7Kg5jDIFAjM@suedonltd.demon.co.uk>, Donald Campbell
<Donald@suedon.co.uk> writes
It would appear that a re-boot allows the backup to complete once. Last
night worked fine. This evening, again a 33 minute gap, no entry in the
backup log and no "ntbackup" entry in the event log.

Don C

"Donald Campbell" <Donald@suedon.co.uk> wrote in message
news:g8eM6pLJc7DIFAFr@suedonltd.demon.co.uk...
This observation should enable to to sit down in front of the
machine and observe what's going on when it fails.

In article <O3XSgfipIHA.524@TK2MSFTNGP05.phx.gbl>, "Pegasus (MVP)"
<I.can@fly.com.oz> writes
The particular machines are 25 miles away.
When I watch via RDC, they work.

Don C

"Donald Campbell" <Donald@suedon.co.uk> wrote in message
news:3tpZOkML4LEIFA$d@suedonltd.demon.co.uk...
A pragmatic solution might be:
- Launch a Remote Desktop connection shortly before the
backup is due to start. You can do this with a scheduled
task. AFAIR, you can use an rdp file that has the password
embedded as a hash value.
This approach will keep your backup going for a while.
- When you get the time, travel to that site to observe the process.

In article <O$RANSkpIHA.1768@TK2MSFTNGP03.phx.gbl>, "Pegasus (MVP)"
<I.can@fly.com.oz> writes
Being on-site for the backups is unfortunately not an option, otherwise
it would have been done.
The Building is shutup tight at that time.

I was considering just not logging out of the RDC session and seeing if
that had the same effect as being connected.

Don.

"Donald Campbell" <Donald@suedon.co.uk> wrote in message
newsWfugtNR1QEIFAuh@suedonltd.demon.co.uk...
Move the backup schedule!

In article <#0wQVRmpIHA.4816@TK2MSFTNGP03.phx.gbl>, "Pegasus (MVP)"
<I.can@fly.com.oz> writes
= User disruption, business loss

Don

"Donald Campbell" <Donald@suedon.co.uk> wrote in message
news:h9Oc6ZOXBbEIFAd5@suedonltd.demon.co.uk...
Mhm. How about running the job while the users are still logged
on? You need to be a little flexible!

In article <g8eM6pLJc7DIFAFr@suedonltd.demon.co.uk>, Donald Campbell
<Donald@suedon.co.uk> writes
According to Remote Storage it is waiting on a mount. I.e. it appears to
be ignoring the /UM and waiting for the last tape to be mounted again.

I did modify the script to do a dummy little backup and then do the main
backup. This evening the first dummy failed after 33 minutes and then
went onto the main event.

So why will it not do the first mount after a tape change?

Don C

"Donald Campbell" <Donald@suedon.co.uk> wrote in message
news:AzU0Z3R8biEIFAJP@suedonltd.demon.co.uk...
I recently had a server that refused to process any tapes. The event
viewer had the message "RSM cannot manage library Tape0. The
database is corrupt." After deleting the database (and forcing a new
one to be created), things went back to normal. I'm afraid I can't
quote the KB article that gave me the relevant details.

Donald Campbell wrote:
why the job is failing.

--

Regards,
Hank Arnold
Microsoft MVP
Windows Server - Directory Services

In article <AzU0Z3R8biEIFAJP@suedonltd.demon.co.uk>, Donald Campbell
<Donald@suedon.co.uk> writes
With the inclusion of an RSM refresh statement before starting the
backup, one site is working. With the inclusion of am RSM eject after
the backup, the other site is now working.

I need to wait until they have worked consistently for a couple of weeks
before I declare success, but it is looking good so far.

Don C

Thanks for the update.