RE: BRMS Recovery Script Questions

Jim,

We do use journaling on about 25 of our files and include the journaled
objects in our BRMS Backup Policy.  From prior DR  tests apyjrnchg was a
bit of fun as we never really have had to use the command so took a bit of
time  .....

Thank you for taking the time to share your thoughts and expertise on BRMS
save and restore strategy. It definitely gave me some things to
re-consider.

PS:  Thanks for the great COMMON sessions you put on by the way !!  The
time, effort and sharing of expertise from all the presenters is very much
appreciated !

 Laura Roberts












From:	"Jim Oberholtzer" <midrangel@xxxxxxxxxxxxxxxxx>
To:	"'Midrange Systems Technical Discussion'"
            <midrange-l@xxxxxxxxxxxx>,
Date:	12/05/2015 05:16 AM
Subject:	RE: BRMS Recovery Script Questions
Sent by:	"MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



The local control point name, network ID and system name are critical for
BRMS.  That will be the source of your biggest problem.  Either study the
recovery guide to be sure you set those attributes correctly or just use
the feature in BRMS to change the database to use the current names.

Why do you omit the directory entry files?  If those are locked during
normal nightly saves you have described, there is a process that is not
very common going on.  Same question for the SNADS queues.  Are you even
using SNA anymore?  I'm guessing the answer is not really; those are just
left over from a bygone era and not cleaned up.  All of those objects will
have to come from the full system save, and while you'll get restored, they
are in QUSRSYS for a reason; they change from time to time.

Performance data (QPFRDATA and QMPGDATA):  I never back up for recovery
purposes but I do back them up for archival in a different process.  Not
needed to get you going again.

Saved changed objects on the IFS are always problematic and I never do it.
The files that are locked by the HTTP servers are generally logs and not
needed for a recovery (since they get recreated if needed anyway) and I
omit them from the daily saves.  We try to get them on the weekend.  It
sounds like your environment you can shut the HTTP servers down
periodically so I would do that.

It also sounds like you set up your saves without the recovery plan in
mind, most folks do.  Consider changing how you think about recovery/saves.
Think how I get this object/library/system back in the event I have to, and
then construct the save to match that plan.  Plan the recovery first, and
then do the saves to support it.  I suspect you'll come up with a different
save structure.

In your case you have a three step recovery.  Do the full recovery first,
then the weekly, then the daily.  BRMS can do the concurrent recovery, and
usually does it well, but any fault in the recovery process will complicate
the steps you need to correct problems.  Start simple and get complex on
your next recovery try.  If you do the concurrent recovery make sure the
tape library has the tapes and is registered in BRMS properly.  (Step 003
in the recovery report)

You don't mention journaling.  Journaling all your application objects is
critical to get the referential integrity of the databases in synch so when
you're doing the recovery planning put journaling into the top of the plan,
and use it.  (Even if you don’t use SQL and commit control in the
applications)   Properly set up journaling does not take that much storage
and the system can manage it for you.  Easy and cheap.

It generally takes three to four recovery tests to get to the point where
the recovery/save steps jive and you get a clean recovery.  Don't be
disappointed if you have issues and it does not completely work, it just
means you have a bit more planning to do.   Convincing management to fund a
more comprehensive recovery test than a once a year dash to the recovery
center is not always easy, but it pays back 1000s of times over if you ever
really have to do a recovery.  There are those of us on this list with the
battle scars to prove it.

--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
LRoberts@xxxxxxxxxxxxxxx
Sent: Monday, May 11, 2015 3:14 PM
To: Midrange Systems Technical Discussion
Subject: RE: BRMS Recovery Script Questions



Hi Paul,

1. Our weekly and daily backups are NOT SWA and not totally dedicated but
we do end Qhttpsvr and punt off any users in Qinter prior to BRMS backup
start. . Very seldom do we get an object not saved and they are only 1 or 2
*DTAQ.

2. Yes we OMIT some library and IFS info from our Weekly and Daily saves:

Qusrsys objects:  omit -> Lcotpjobs, Qa1psc, Qaokp01a, Qaokp04a, Qaokp08a,
Qaop09a, Qasnadsq, Qusrdirdb object: Qgldlock
Qmpgdata:  All omitted

IFS:
/QSYS.LIB
/QDLS
/TMP/BRMS
/QIBM/ProdData
/QOpenSys/var/log and a few more logs

How did you work around your saved changed IFS obj issues ?

Thanks


Laura Roberts
System Administrator, Information Systems and Technology

306.667.5260
Saskatchewan Blue Cross
sk.bluecross.ca I push2play.ca

Please consider the environment before printing this email.










From:		 "Steinmetz, Paul" <PSteinmetz@xxxxxxxxxx>
To:		 "'midrange-l@xxxxxxxxxxxx'" <midrange-l@xxxxxxxxxxxx>,
Date:		 11/05/2015 01:46 PM
Subject:		 RE: BRMS Recovery Script Questions
Sent by:		 "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



1) Are your weekly and daily saves dedicated, SWA, or other?
2) Do you intentional omit any library objects and/or IFS objects?

I did a similar test back in May 2013.
1) Missed and locked objects from the save were was the main reason for
recovery issues.
2) Recovery of IFS from an IFS changed object save also had issues.

Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
LRoberts@xxxxxxxxxxxxxxx
Sent: Monday, May 11, 2015 2:46 PM
To: midrange-l@xxxxxxxxxxxx
Subject: BRMS Recovery Script Questions


Hi,

We will be performing a DR test next month on a system supplied by IBM for
our test. We will be using BRMS Recovery script for the first time. I have
a couple of questions in regards to the BRMS recovery script if anyone
would like to share their expertise it would be very much appreciated.

Background:
We are on V7.1  Cume TL14283 and TR 9  Our recovery strategy includes 3
media tapes: (as we do not perform *savsys nightly) and yes we save our
access paths with each save.

1. *savsys (monthly) entire system save  Media: SI0176
2. *savlib (weekly)                                      Media: SI0159
3. *savchgobj (daily cumulative)               Media: SI0009

Questions:

      1. Update System Name in the BRMS Media Information step:  In a DR
test and restoring from savsys would the local network and default local
location on the new test system be the same anyway or am I missing
something ?

   2.		 		  In the step of :Recover Required System
Libraries:  (snapshot
below)
      Can I select all 6 selections below all at once even though the media
      switches back and forth weekly to daily at each library and the fact
      that daily is a *Cuml type. Is BRMS smart enough to do the savlib and
      savchgobj restore. Or does it make sense for me to only select just
      the weekly ones first then does the screen come back to be able to
      select the daily ones (speed perspective) so not to have to unload
      tape media so often ?

(Embedded image moved to file: pic27901.gif)


   3.		 		  Has anyone used the Recover Media sets
concurrently step ?
Pros/Cons

   4.		 		  If I don’t use the Concurrent option, do most
people Recover
All
      Remaining System and User data at this point (then jump to the
      Recover Directories and Files as the script says) Or would you
      recommend doing the more separated BRMS recovery script steps by
      “Recover IBM  Product Libraries, then Recover user Libraries, then
      Recover Documents Library Objects then get to the recover Directories
      and Files) ?

Any tips/gotchas or recommendations ?

Thanks so much

Laura Roberts



This communication, including all attachments, is for the sole use of the
intended recipient(s) and may contain confidential, personal and / or
privileged information. Any unauthorized review, use, disclosure or
distribution is strictly prohibited. If you are not the intended recipient
or a person responsible for delivering this message to an intended
recipient, please contact us immediately so we may correct our records.
Please then delete or destroy the original transmission and any subsequent
reply.
--
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.

This communication, including all attachments, is for the sole use of the
intended recipient(s) and may contain confidential, personal and / or
privileged information. Any unauthorized review, use, disclosure or
distribution is strictly prohibited. If you are not the intended recipient
or a person responsible for delivering this message to an intended
recipient, please contact us immediately so we may correct our records.
Please then delete or destroy the original transmission and any subsequent
reply.
--
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.

This communication, including all attachments, is for the sole use of the intended recipient(s) and may contain confidential, personal and / or privileged information. Any unauthorized review, use, disclosure or distribution is strictly prohibited. If you are not the intended recipient or a person responsible for delivering this message to an intended recipient, please contact us immediately so we may correct our records. Please then delete or destroy the original transmission and any subsequent reply.