Backup IFS funktioniert nicht

[UFi]

Wir sichern oder besser gesagt wollen im Nachtjob u.a. auch das IFS sichern.
Gesichert wird auf ein IBM LTO3 3573.
Die Maschine ist nicht im eingeschränkten Zustand.
Die Sicherung bricht mit der Msg CPF5101 (Schnittstellenfehler bei Verwendung von Einheit TAP01) und MCH1668 (Systemobjekt TAP01 teilweise zerstört) ab.
Alle vorigen Sicherungen (Bibl., DLO, etc.) gehen anstandslos.
Ich vermute einen Lock auf irgendein Objekt, welcher dann in diesen wenig aussagenden Fehlermeldungen endet.
Test mit kleineren Ordner vom IFS im Tagesbetrieb funktionieren reibungslos.
Das Web hab ich nach Instruktionen bzgl. dem richtigen Vorgehen beim IFS-Backup durchsucht, aber nichts hilfreiches gefunden.
Ich vermutete einen evtl. Lock von einem Server und beende zwischenzeitlich auch das TCP, hat aber auch nichts gebracht. Die Sicherung wird vom QSECOFR ausgeführt, es sollte also kein Berechtigungsproblem sein.
Ich vermute nun ein nicht beendetes Subsystem.
Hat vllt jemand gleiche Erfahrungen oder eine Anleitung zum korrekten Vorgehen beim IFS-Backup?

[Fuerchau]

Dann solltest du mal bei der Sicherung eine Detailausgabe machen, dann siehst du wenigstens wie weit er kommt.

[UFi]

Laut Joblog sichert er gar nichts. Das ist ja das Schräge daran. Der bringt die CPF5101 gefolgt von der MCH1668 und noch ein paar weiteren alle das Objekt TAP01 betreffenden und bricht dann ab.
Anhand der Zeiten im Joblog seh ich aber, dass er ewig braucht bis die CPF5101 protokolliert wird.
Zuerst dachte ich an ein Problem der Bandeinheit, die ist neu, aber da er im Test einen Ordner aus dem IFS problemlos sichert, muss ich das wohl ausschliessen.

Vielleicht gibt's hier ja doch jemand der das komplette IFS im nicht eingeschränkten Zustand sichert.

[Pikachu]

Wie sieht denn dein SAV aus?

Das sollte im laufenden Betrieb gehen:

SAV DEV('/QSYS.LIB/TAP01.DEVD') OBJ(('/*') ('/QSYS.LIB' *OMIT) ('/QDLS' *OMIT))

[UFi]

Jau, so sieht er aus
SAV DEV('/QSYS.LIB/TAP01.DEVD') OBJ(('/*') ('/QSYS.LIB' *OMIT) ('/QDLS' *OMIT)) SAVACT(*YES) ENDOPT(*REWIND) UPDHST(*YES)

Da ich immer noch einen Lock vermute, hab ihn so bisher im Tagesbetrieb noch nicht durchgeführt, werde ich morgen aber gleich mal versuchen. Schaden kann's ja nichts.

[Fuerchau]

Bei SAVACT(*YES) sollte man noch eine kürzere Wartezeit (Default 2 Minuten)angeben, da beim Auftreten mehrerer Sperren die Zeit je Objekt gilt. Bei 10 Sperren sind das ja schon 20 Minuten Nichtstun.

Beim IFS-Sichern würde ich auch die Systemeigenen IFS'n nicht sicher (z.B. QIBM, QFileSrv.400, QNTC usw.) und wirklich nur die eigenen (z.B. /Home).
Wenn nämlich diverses Server (HTTP o.ä.) laufen können viele IFS-(System-)Objekte im Zugriff sein.

[holgerscherer]

Jau, so sieht er aus
SAV DEV('/QSYS.LIB/TAP01.DEVD') OBJ(('/*') ('/QSYS.LIB' *OMIT) ('/QDLS' *OMIT)) SAVACT(*YES) ENDOPT(*REWIND) UPDHST(*YES)

Da ich immer noch einen Lock vermute, hab ihn so bisher im Tagesbetrieb noch nicht durchgeführt, werde ich morgen aber gleich mal versuchen. Schaden kann's ja nichts.

Hallo Ufi,
eine Frage - hängt das Tape an eigener Schnittstellenkarte, mit oder ohne IOP? Eventuell auch ein Timeout, wenn das SAVACT() zu lange benötigt. Im Notfall auch die DEVD löschen und RCLSTG, falls noch nicht gemacht.

Solltet Ihr viele IFS-Ordner mit vielen kleinen Files haben, wäre das schrittweise Sichern einzelner IFS-Ordner eventuell besser.

-h

[UFi]

Hab heute den entscheidenden Tipp bekommen. Da ich nicht im eingeschränkten Zustand sichere, sind wohl im IFS Objekte im Zugriff vom Betriebssystem.
Da wir vor jeden Systemarbeiten einen savsys machen, genügt es vollkommen im Tagesbetrieb nur die Anwendungsordner zu sichern.
Danke für die Antworten.

@Holger: Bei meiner Recherche im web bin ich u.a. auf ein Posting gestossen, welches eben auch auf Hardware-Probleme hinwies und mit PTF gelöst wurde. Da ich aber wie geschrieben im Tagesbetrieb sichern konnte, hab ich das verworfen.

[UFi]

Und es kam alles ganz anders. Die letzten meiner naturfarbenen Haare habe ich verloren.
Lange Rede kurzer Sinn: Das LTO-Tape 3573 arbeitet bei bestimmten Releaseständen nur zuverlässig mit Glaskabel.
Unter Release 5.4 funktionierte ja nur die IFS-Sicherung nicht (Thread-Thema).
Als wir dann auf 7.1 umgestellt haben ging gar nichts mehr.
Zu diesem Zeitpunkt waren die beiden beinhalteten Bandeinheiten noch mit SCSI-Kabel angeschlossen.
Erst als die Bandeinheiten gegen welche mit Glaskabel-Anschluss ausgetauscht wurden funktionierte die Sicherung wieder ordnungsgemäss.

Die ganze Geschichte hat uns und den Hardware-Lieferanten Stunden und Tage gekostet. Woher letztendlich der entscheidende Tipp kam kann ich nicht sagen.
Die Konfiguration wurde vom Lieferanten mit dem IBM-Konfigurator durchgeführt und dieser hat keinerlei Hinweis auf diese Problematik gegeben.

Die Umstellung auf diese 3573-Bandeinheit erfolgte im Zuge einer Server-Virtualisierung. Vorher sicherten wir unter 5.4. alles problemlos auf die interne Bandeinheit der 550.

[UFi]

Es klärt sich ein bisschen weiter.
Das Problem besteht wohl nur bei Power5-Maschinen im Release 7.1.
Bei den Power7 hat die IBM die SCSI-Unterstützung gekündigt, dort kann die Bandeinheit nur noch mit Glas angeschlossen werden. Allerdings gibt es auch hier noch einen Kontroller der das doch noch ermöglicht. Da soll einer durchblicken.