PDA

View Full Version : Abbruch beim Zurückspeichern der QUSRBRM beim Wiederherstellen des Systems mit BRMS


fedcba
06-08-20, 15:17
Hallo,

als IBM i Neuling lese ich schon länger hier im Forum, habe nun in der Firma aber ein Problem für das mir keine weiteren Lösungsansätze mehr einfallen und hoffe, dass hier vielleicht noch jemand einen Ansätze wüsste.


Wir versuchen mittels einer BRMS erstellen Offlinesicherung das kompletten System einer LPAR (IBM i 7.1) auf einer LPAR einer anderen Maschine (Power 520 Express - 8203-E4D) zu migrieren.

Gemäß "BRMS Wiederherstellungsreport" und "IBM Sicherung und Wiederherstellungs 7.1" Dokumentation haben wir zunächst die LPAR auf der Zielmaschine mit einem IPL DM von der LIC 7.1 DVD gebootet, den LIC installiert und das IBM i OS wiederhergestellt.

Bei Punkt 4 des BRMS Wiederherstellungsreport gelingt es uns die ersten vier Bibliotheken mittels RSTLIB zurück zu spielen, die letzte Bibliothek (QUSRBRMS) kann aber nie komplett zurückgespielt werden. Der Vorgang bricht immer bei ca der Hälfte ab, so dass nur die Hälfte der Objekte zurück gespielt werden. Im Joblog sieht man dass der Abbruch stets bei der Datei QA1ADI2 mit dem CPF3734 erfolgt (Objekte konnte nicht zurückgespeichert werden, da es während des Rückschreiben möglicherweise beschädigt wurde). Für alle nachfolgenden Datein wird dann der Fehler CPF3755 aufgeworfen.
Auch ein RSTOBJ nur der QA1ADI2 war erfolglos.


Wir haben schon den RSTLIB mit unterschieldichen Werten für ALWOBJDIF (*COMPATIBLE, *ALL) versucht, ohne Erfolg. Diese QUSRBRM Bibliothek konnten wir auf einer anderen Maschine und auch auf einer anderen LPAR der selben Maschine und mit derselben LIbrary allerdings einwandfrei wiederherstellen, so dass wir einen Defekt des Bandes oder der Library ausschliessen können.

Hätte hier vielleicht noch jemsand einen Hinweis für uns, in welcher Richtung wir hier noch schauen könnten ?

Danke und Gruß
Andre
Fuerchau
06-08-20, 18:01
Kannst du auf der Ursprungsmaschine den Typ des Objekts prüfen?
Ggf. ist es ja nur ein Index (xxxI2), den du dann neu erstellen könntest.
Somit kannst du das Objekt dann umgehen.
Auch wenn ein Objekt ggf. auf eine andere Lib verweist und diese dann (noch) nicht da ist, scheitert der Restore.
fedcba
07-08-20, 10:34
Danke für die Rückmeldung.

Wir haben stichprobenartig nachgeschaut: Die Objekte, die nicht wieder hergestellt werden können, sind jeweils physische Datein (wobei einige andere physische Datei wiederhergestellt werden). Wir können hier nicht erkennen was an diesen Dateien anders ist als an den anderen. Wir haben auch mal die entsprechende Datei aus dem RSTLIB mittel OMITOBJ herausgenommen, aber auch dann bricht das Wiederherstellen bei der nächsten Datei ab.

Einige der Datein, die nicht wiederhergestellt werden könne, sind tatsächlich Indexdatein, die meisten aber nicht.

Wir sind (schon allein aus Neugier) für weitere Hinweise dankbar. Aktuell haben wir die Vermutung dass unsere Tape-Library im Zusammenhang mit einem frischen 7.1 LIC und dem wiederhergstellten Betriebssystem irgendeinen Fehler aufweist. Wir haben auch tatsächlich ein PTF für 7.1 mit genau diesem Fehlerverhalten gefunden (RSTLIB bricht u.U. ab wenn SEQNBR angegeben wird) und den SEQNBR Parameter daraufhin mal weggelassen, auch ohne Erfolg.

Als workaround werden wir nun als nächstes versuchen, LIC und IBM i 7.1 mitsamt Cum-PTF auf die neue LPAR zu installieren und dann nur die Einstellungen und Benutzerdaten der "alten" Maschine vom Band wiederherzustellen.
Fuerchau
07-08-20, 12:40
Wie sicher bist du denn, dass der SAVE funktioniert hat?
Probier einfach mal ein Restore in eine andere Lib. Ggf. ist das bereits die Ursache.
BenderD
07-08-20, 13:00
... ich tippe mal eher auf einen Bug in dem Brumms-Gelums.

D*B
holgerscherer
07-08-20, 13:43
Wir versuchen mittels einer BRMS erstellen Offlinesicherung das kompletten System einer LPAR (IBM i 7.1) auf einer LPAR einer anderen Maschine (Power 520 Express - 8203-E4D) zu migrieren.


Hallo Andre,

nur um Dir das Leben zu vereinfachen: Welcher Spassvogel hat Dir diese Vorgehensweise empfohlen?

GO SAVE,21 - und Restore 21 auf dem Ziel ist viel schmerzloser.
fedcba
10-08-20, 11:51
Wie sicher bist du denn, dass der SAVE funktioniert hat?
Probier einfach mal ein Restore in eine andere Lib. Ggf. ist das bereits die Ursache.

Das war auch unsere Vermutung. Auf anderen LPARs konnten wir diese Library mittels RSTLIB aber ohne Probleme zurück spielen. Einer der Test war dabei sogar auf einer anderen LPAR auf der gleichen Maschine mit demselben Archivsystem erfolgreich, so dass wir auch einen Fehler im Archivsystem ausschliessen können.
fedcba
10-08-20, 11:56
Hallo Andre,

nur um Dir das Leben zu vereinfachen: Welcher Spassvogel hat Dir diese Vorgehensweise empfohlen?

GO SAVE,21 - und Restore 21 auf dem Ziel ist viel schmerzloser.

:D Wir machen von der Quellmaschine regelmässig eine Offlinesicherung des gesamten Systems mittels BRMS und dachten, das es der beste Weg für eine Migration sein würde uns an den entsprechenden Wiederherstellungsreport von BRMS zu halten.

Wir werden nun deinen Ansatz in den nächsten Tagen ausprobieren.

Noch einmal Danke an Allen.
holgerscherer
10-08-20, 12:56
:D Wir machen von der Quellmaschine regelmässig eine Offlinesicherung des gesamten Systems mittels BRMS und dachten, das es der beste Weg für eine Migration sein würde uns an den entsprechenden Wiederherstellungsreport von BRMS zu halten.


An sich ist das auch ein guter Weg - nur sehr fummelig, weil sich die BRMS-Routinen ins System einklinken. Daher ist die QUSRBRM notwendig, sonst weiss BRMS nicht, wo oben ist. Für eine reine Migration lieber den Weg des geringsten Widerstands gehen.

Und nachher INZBRM nicht vergessen ;-)