Backup Exec 2010 R3 Kopie auf Band bleibt hängen "Katalog wird aktualisiert"

[J_Strobel]

Hallo Forum,

wir haben bei einem Kunden seit ein paar Tagen ein seltsames Verhalten.

Der Server (HP DL380Gen8) ist ein Windows 2008R2 mit Installiertem Backup Exec 2010 R3.

Es werden div. Server klassisch im D2D2T Verfahren gesichert.

Das Backup Exec sichert div. Server mittels Agenten (gleicher Patchstand wie Hauptprogramm) auf ein ISCSI Storage täglich differenziell und am Wochenede vollständig.

Dieser Job wird abgearbeitet und abgeschlossen.

Anschliessend läuft ein an den ersten Job angehängter Kopierjob und kopiert die auf dem ISCSI-Storage befindlichen Daten der Sicherung aus dem ersten Job auf einen LTO-4 SCSI Bandwechsler.

Nun haben wir das Problem, das der Kopierjob anfängt, das Band zieht und beginnt zu schreiben. Die Übertragungsrate liegt bei 1500-1700MB/min. Es wird auf das Band geschrieben bis ca. 210GB dann springt die Anzeige des Auftrags von "Ausführen" in  "Kataloge werden aktualisiert". Ab diesem Zeitpunkt werden keine Daten mehr geschrieben, und die Übertragungsrate nimmt stetig ab (ist auch klar...) Aus diesem Status kommt der Job nicht mehr raus. Auch mehrere Stunden später nicht (60 Std. am WE vor Abbruch durch den Admin).

Mit dem BEUtility haben wir bereits die Datenbank auf Fehler geprüft, Indexe neu geschrieben, komprimiert und erneut auf Fehler geprüft. Hier kam kein Ergebnis, alles ok. Alle Dienste des BE laufen und sind nicht beendet. Das ISCSI Device hat/hatte in dieser Zeit keine Verbindungsabbruch, auch der Bandwechsler ist weiterhin Online.

Im Virenscanner (Trend Micro) wurden die entsprechenden Verzeichnisse des BE und B2D-Ordner ausgenommen und auch schon mit deaktivierten Virenscanner getestet. Auch wurde schon getestet alle Insight Agents auf deaktiv zu setzten. Problem bleibt gleich bestehen.

Was kann dieses Verhalten auslösen, bzw. was kann hier der Fehler sein. Über Hilfe würde ich mich freuen.

[CraigV]

...have you restarted the media server, and also made sure that the Symantec drivers are being used for the drive itself?

Is there enough disk space available on the drive holding the BE catalogs?

Thanks!

[J_Strobel]

Hello,

the Catalog is on C: Drive which is about 260GB free. Media Server restarted serveral times (after making changes to Virusscan and after changing the Insight Management Agents from HP and a few times more ;)and check that all Updates run succsecfully and nothing in the Queue for a reboot. B2D Drive still have 6TB left.

Symantec Drivers are installed for the Library and the Drive and no other Programms use the Library.

[lmosla]

Hello J.Strobel,

Are you are fully patched up to Backup Exec 2010 R3 SP4 
http://www.symantec.com/docs/TECH208828

Do you have any errors in Window Even Logs?

Edit:

Also try recreating the job keeping database files and flat files in seperate jobs

[J_Strobel]

Hello,

the Catalog is on C: which is about 260GB free. The B2D Drive is about 6TB free.

Restarted the Server serveral times. (After Configuring Virusscan; Insight Agents) I made sure that the Update Queue from Windows is empty and that the Server dont need a reboot.

The Symantec Drivers for the Library and the Tape Drive are installed. No other programm ist installed nor uses the Tape Drive or the Library

[J_Strobel]

Thanks for help, will try recreating the Jobs and give feedback.

C: is about 260GB free; B2D Drive ia about 6TB free. Rebooted the Server serveral Times. No other Program uses Tape or Library. Symantec Drivers are installed.

[pkh]

You should uninstall the HP Insight software. It causes problems with tape drives when using BE

[J_Strobel]

Hello, just installed SP4 für R3 recreated all Jobs, but same Problem. After ~230GB to Tape Job hangs with "KAtaloge" werden aktualisiert :)

Will try Deinstalling Insight Agents, but the Jobs worked the last 2 Years with Insight Agents installed... :(

Maybe someone knows what BE is doing here. And which Services are involved...

Thanks for help

[VJware]

I am assuming you are duplicating GRT enabled backup sets to tape. If that's the case, the IMG folders which are present in the Disk location are being enumerated so that the catalog information is being created.

This stage can take time depending upon various factors such as number of individual items, size of the application/DB, AV scanning the disk, high disk I/O etc and not necessarily the issue lies with the tape storage itself.

If you are duplicating all backup sets at once to tape, split the duplicate jobs such that GRT enabled backup sets are being duplicated separately from the non-GRT backup sets. Also, if possible, how long does it take for a direct GRT backup to tape to run instead of disk ?

[J_Strobel]

Hello, i tried disabling GRT on the Job this weekend, and for now all looks fine.

Some server are on slow connections, so direct Backup to Tape will slow it down, because the Tape wont use the Streaming mode and work in "StopnGo" (or however this is called) which will take very long time, and kill the drive earlier.

Will try enabling GRT after the Weekend Job, which is still running and give Feedback.

Separating Jobs is problematic, because the Customer have to watch the Logs and the Backup for himself, so it have to be easy as possible. (Which worked for a few years now until last week...)

Why fighting BEs own Problems with its own data :(..