Re: Backup Performance

I haven't dealt with backup/restores in decades, but doesn't encrypting the backup, even on the drive, take additional time over doing an unencrypted save?

I would think that much of the difference would be saving the system libraries unencrypted rather than encrypted(?). The system libs, in many shops, are larger than the business data.

Duane Christen


--


               Duane Christen
Senior Software Engineer
(319) 790-7162
Duane.Christen@xxxxxxxxxx

Visit PAETEC.COM


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jim Oberholtzer
Sent: Friday, October 01, 2010 9:43 AM
To: Midrange Systems Technical Discussion
Subject: Re: Backup Performance

 Douglas:

Wondering out loud (or on line as the case may be) You have to consider because QCTL is still active, albeit all the other user subsystems are shut down, the system is not really in a restricted state so there are more services available to manage jobs, memory and such.  You did not say if you shut down QUSRSYS  and QSYSWRK or not but I suspect that may be part of the equation.  When the system is nearly fully functional (the semi state you are indicating) all the things that make the system able to handle multiple jobs, threads, I/O etc are working, and helping you out, versus the restricted state where many of those services are shut down, since there would not be any expectation of doing real work other than back ups.

Jim Oberholtzer
CEO/Chief Technical Architect
Agile Technology Architects, LLC


On 10/1/2010 9:03 AM, Hart, Doug - EI wrote:

We have always done a full system save (like opt 21) on the weekends using BRMS.  For sometime now we have been encrypting our tapes via our LTO4 tape library.   These were always done in Restricted State.  Well we talked with our auditors and got the OK to not encrypt the OS and other IBM ("Q...") libraries.  This greatly helps simplify the restore of the system (we do practice D/R).  We only need to encrypt our company's data.  So we have modifyed our BRMS control groups again so now we save (encrypted) all of the *ALLUSR and IFS 1st.  What I did differently is code (API) a step that ends all active subsystems EXCEPT QCTL for the encrypted save.  Then we go restricted and get the remainder of the system.

OK, if you followed me so far here is the question.  We have a number of LPARs on several systems.  All at v5r4 and using fiber to the tape library.  Our backups are running faster and we're not sure why.   The most dramatic change has been on our smaller partitions, ones with little CPU and memory allocated.  I'm talking ½ the outage window, 12 hours down to 6 hours.  My 1st thought was maybe the difference in not going down to an actual Restricted State was the *SHRPOOL memory was being better allocated to the backup job.  But this doesn't seem to be the case.  Remember that only QCTL is running and BRMS is still doing the save.

I talked with Support Line work management and didn't get much.  They suggested using the Flight Recorder to monitor the backups.  They looked at this differently, saying that maybe the old procedure was slower than it should have been and we just corrected some long standing issue in our shop.  We have double checked the backups and we are getting everything, it's not like we are only saving half of or systems.

So, anyone out there want to offer a suggestion as to why our outage window is so much improved?








Douglas Hart  -  Principal Consultant

--
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.