Re: Backup - revisited

I received an email from the sa. The tone was somewhat more civilized than in
the meeting. He attached a document describing some issues. I will
paste some
of it here, as this might make more sense to others:

During this time a GO SAVE 21 had to be performed on the old hardware to
capture the data and necessary meta-data required to perform the conversions.

A restore and conversion procedure was available on the new server that
read the
meta-data and performed the necessary conversions.

The GO SAVE process does a lot more than just execute back up commands.

Each time that I worked with IBM support the first thing they asked was
did you
perform a GO SAVE 21.

IBM agreed we were executing all of the right commands using our SFHC custom
back up procedure, but was unable to give me a definitive reason as to why I
could not restore all of our IFS directories.

I remember working with IBM on a SAVE problem following the application
of PTFS.
I ended up having to omit the /QNTC file system to get it to work again. This
was done with IBM's blessing. The GO SAVE 21 procedure saves the /QNTC file
system without a problem. The QNTC file system is the windows server file
system.



Does any of the above clarify anything??

John McKee

Quoting CRPence <CRPbottle@xxxxxxxxx>:

That this was an upgrade from v5r2 to v5r4, so the restore was
actually part of an upgrade scenario versus a standard DR, the origin of
the problem in understanding this issue is probably now clear. It seems
that the discussion is not about DR, but about an _upgrade_ that is
performed with _data migration_ from a prior release. There are a
variety of data migration strategies. When an upgrade is thrown in, the
best choice is based on the capabilities of the hardware support for the
release levels involved. Ideally the target system can be installed to
the release level of the source system with only the LIC & OS, to which
the restore-21 is performed, where the target is then upgraded from the
lower to the higher release level; ideally, because that limits the
number of release upgrades to just one.

The most common failure in such upgrades is for an *assumption* that
it can be done simply by restoring stuff, rather than following a well
understood and tested migration path. And for failure to follow the
path with a good checklist, most typically the biggest problems are a
direct result of improper migration of the user data in quasi-system
user libraries, primarily QUSRSYS and QSYS2. As such my guess is, that
rather than anything properly termed metadata being at issue, the issue
is user data. Although it is called /user data/ because it was supplied
by the user\operator to an application on the server, on another
platform it might be called instead, /application data/; where in this
case, the "application" is the OS.

Regards, Chuck

Ingvaldson, Scott wrote:

Additional information from John:

When BBACKUP was used, ENDSBS OPTION(*IMMED) preceeded BBACKUP. The
commands used by BBACKUP are:

SAVSYS DEV(TAP35) ENDOPT(*LEAVE) SAVLIB LIB(*NONSYS) DEV(TAP35)
ENDOPT(*LEAVE) ACCPTH(*YES)
SAVDLO DLO(*ALL) DEV(TAP35) ENDOPT(*LEAVE)
SAV DEV('/QSYS.LIB/TAP35.DEVD')
OBJ(('/*') ('/QSYS.LIB' *OMIT) ('/QDLS' *OMIT) ('/QNTC' *OMIT))
ENDOPT(*UNLOAD) UPDHST(*YES)

The SA attempted to restore from 820 (?) to 520. I was not present
when he did this. All he offered was that the metadata was not
saved by the above commands. I asked what was included in the
metadata, and got no answer. When I showed him a page from
infocenter detailing the processes used by option 21, he stated
that *something* is different.

Stated that he had been on the phone with IBM for weeks.

Old box was v5r2 and new box is at v5r4. I have NO idea what was
loaded on the new box.

All of this is to do DR planning at some point. He even stated that
option 21 was also non functional. But he quickly moved on. This
makes absolutely no sense to me.

Does any of this help? Any additional information that I might be
able to dig up that could be worthwhile?

Our mutual supervisor has asked me to contact IBM support for
clarification. I would dearly like the call to be worthwhile. But,
I already see that I am missing a considerable level of detail. For
starters, what did he do, on what kind of system.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.