Re: Backup - revisited -- MIDRANGE-L

As I understood it, the whole point of the Save-21 is to be generic enough to eliminate any silliness like the work being done in steps three to seven [of the quoted text]. Most notably, all upgrade & PTF activity that was already applied to the system, would still be there after the restore. Anything contrary to that outcome, would seem to me, to be a glaring defect in the use of SAVE-21 for DR. I would expect that "IBM sez they'll note this in a future PTF" means to suggest that IBM will *correct* that problem in a future PTF.? There should be very little WebSphere could do to defeat the normal DR. What is the APAR that documents the problem whereby WebSphere "does NOT work" for a standard DR via restore from a save-21?

Note: During an /attended IPL/ there is panel presented with an option to process PTFs. Because it is an attended IPL, the panel presented to enable PTF activity for both application & removal, functions as an override to any PTF actions that may have been established prior to the IPL. IIRC the option for all of the PTFs listed, is blank to represent no action, rather than reflecting any pre-pwrdwn setup.

Regards, Chuck

PaulMmn wrote:

<<SNIP>>

We've had problems getting web-based applications to run during our
hot site tests. We're running v5r4 on 2 Mimixed 550 systems.

I thought Save/21 and Restore/21 should be enough to put everything
back together! Because we don't have the time to do a full daily
Option 21 (and because some backups are done from our Mimixed
machine), we have to re-assemble our system from pieces of 2 machines
(although OS, PTFs, Compilers, WebQuery, WebSphere, HTTP, and JAVA
are from the 'master' system). We do a monthly Option 22 backup, plus
daily backups of libraries and IFS.

Normal 'library-based' applications seem to work OK with Save/Restore
using SAV/RSTLIB commands.

I know that Web Sphere does NOT work with Save/Restore option 22 (or 21)! IBM sez they'll note this in a future PTF... Anything
web-related seems to be problematic. Our problems were worse with
WebSphere, HTTP, and JAVA.

Our procedure for our disaster recovery tests will now be:

1) Restore everything from a GO SAVE Option 22. This includes IPLing from CD #1, then loading microcode and everything else from tape. It
is important that microcode is loaded from tape-- you need to include
all customized PTFs &c.

"The use of the optical media in the recovery was due to the tape
drive not being configured as an alt-IPL device"- but there is an
option (in the backup/recovery guide) in the section "restoring to
new and different hardware" (or something like that) to let you IPL
from the CD, then do everything else from a tape (including loading
microcode).

2) Restore everything else (including all of the IFS). During our
test we eventually did this in restricted state-- it didn't seem to
take much longer than firing up enough subsystems to run 2 or more
threads.

3) Delete 5733w60 (WebSphere) from the system

4) Install 5733w60 (WebSphere) from the distribution CDs. The delete/install left our applications alone during our tests... BE
CAREFUL!

5) Install PTFs for HTTP, JAVA, and W60 (GO PTF Option 8)

6) IPL (And make sure -all- of the PTFs apply-- we were IPLing in 'attended' mode, and it ignores any 'apply PTF' settings made during
GO PTF. Ask me how I know!)

7) Run the WebSphere Updater, specifying Java -devkit14... we have multiple versions of Java on our machines, and the updater is fussy about which version it likes to run under!

In QSHell /qibm/proddata/websphere/appserver/v6/base/updateinstaller/update -devkit14

8) Fire up everything

My current thoughts are to keep the latest 'W60 CD and PTFs in Image Catalogs in the IFS, so they're always available from our backup
tapes.