BE 8.6 - Backup fails on verify

[Technative]

Hi all,

I have the following problem. First the situation:

There are two servers, one running Exchange and BE 8.6, the other running some SQL databases for financial software (it is also running teh BE remote agent). Both servers are running Windows 2000 Advanced Server).

Total backup size is around 35 to 36 Gb. The tapedrive is a Compaq DLT 20/40 and the 20/40 tapes are used.

The problem is, that the backup runs ok, but in the verify procedure something goes wrong, which causes the backup to fail, and every 10 minutes or so, an "operator attention": message is sent to Administrator asking to remove the media from the drive. The message:
-------------------------------------------------------
A Backup job has failed.

(Server: "SRV02" Job: "Dag" Device: "COMPAQ 1&quot Please remove the media from the drive.
-------------------------------------------------------

When then the tape is removed, the message pops up that another tape is requested

The problem first occurred, after the normal backup operator left a cleaning tape in the drive by accident when I was on sick leave (had my wisdom teeth pulled )so that one backup failed. After thatr no backup job ever completed succesfully.

Until recently, they have been using Type III 10/20 Gb tapes. Now changed to Type IV 20/40 Gb tapes (supported by the drive), but to no avail. Result stays the same.

I already tried software and hardware compression and the overwrite protection period is set to 1 hour.

I also verified if all remote locations are available and accessible; all no problem. Also tried to relable all tapes (and erase all data in that operation). Also tried to retire all media, delete them and create a brand new media set, but all that did not work as well.

What I also found, is that since the last succesful backup, the backup period has suddenly quadrupled in duration. A normal backup of 4 hours, now suddenly takes over 16 hours to complete (in spite of the fact that the average throughput to the drive is still around 150 Mb).

Any ideas anyone? I'm about to start doubting myself... What's the way to go? Upgrade firmware? It's always been running fine until now... Patches for Backup Exec perhaps?

Thanks a million!

Paco

 

[Bayloff]

1st i would try cleaning the Drive 4-8 times in a row.
then i would try to backup about 100 meg off one of the systems to make sure that the drive was working fine.
In a Perfect Drive. But in Real world you will get about 1.2-1.6:1 compression.
so you may be blowing the tapes capacity. try not backing up so much and seeing if that works.
wel that's my 2 cents worth

 

[Technative]

Bayloff,

Thanks for your suggestion. I found out one other important thing: The drive made over 1800 soft write errors in 1007 hours of operation... Think that says it all.

On a brand new tape (DLT IV 20/40) I backup up around 5 Gb. This worked fine. Don't know how much space is left on the tape though...

Tried cleaning it 5 times in a row, but this did not improve much.

My conclusion is that the drive is about to follow the light...

By the way, what is the MTBF on those things? This drive is about 4 years old. Granted it's been doing a 3 to 4 hour backup and verification every night, but still...

Thanks for your help!

Paco

 

[SQLBill]

Before you replace the drive, have you tried powering it off and back on again (rebooting)? Give that a try first.

-SQLBill

 

[Technative]

Hi Bill!

I already rebooted the complete server several times actually. I also tested it with the L&TT tool (HP). All tests were passed successfully (communication, SCSI-adapter, read-test, write-test, etc...).

However, the drive statistics in Backup Exec showed around 1800 soft-write errors in 1000 hours of operation, and 1 hard write error. Decided to replace the drive (within a few months the capacity of the drive would be insufficient anyway). We now got a Compaq 110/220 SDLT drive.

Uninstalled all veritas drivers, reinstalled them, installed new drivers in Windows 2000, also upgraded the drive to the latest firmware (V051) with the L&TT tool, ran all tests (all succesful), removed existing all media (from the old drive) from the mediaset, created a new mediaset, ran an inventory on all new SDLT tapes and labelled them, set overwrite protection period on the new mediaset to 0, removed the old job and created a new job definition with a new schedule (removed existing scedules). This is the only job in the job definition window.

I also disabled the drive in Removable Sorage (W2K).

Tried a small manual backup and all ran OK. Inserted a new tape (which in it's lafe has only been inventoried and labeled), and... the next day my mailbox was full with "Operator Attention" messages...

This makes me so sick!

The message is a little different this time though. Before (with the old drive) the message was "please remove the media from the drive". Now the message is "please insert overwritable media". The tapes are not write-protected.

Any ideas / suggestions? I have run out of ideas... The only thing I can think of is a total uninstall and reinstall of Backup Exec, and I'm not even sure that is going to work...

Any suggestion is VERY welcome!

Thanks,

Paco

 

[rummly]

Paco,

Try moving the tape to "Scratch Media" when you get this error.

Thanks :

 

[Technative]

Good news! Backups now run ok, but only after I removed the system state of the remote machine from the backup list.

Error in the log is: unable to attach to \\srv01\System%20State

No further details are mentioned as to why it was not able to attach to the system state on the remote machine. All other items (SQL database, Exchange server and several user-shares) are backupped ok; only the system state is giving problems. The system state on the local machine can be backupped ok, so only he remote machine is causing problems.

Any ideas anyone?

Many thanks in advance...

 

[SQLBill]

Permissions? Maybe BE doesn't have the proper permissions to access the system state. Check with the sysadmin (if you aren't that person), maybe setting BE as BACKUP ADMIN or SYSADMIN privileges will work (allowing sysadmin privileges is not a good thing, but if nothing else works......)


-SQLBill