BRMS backups stretching

175 pts.
Tags:
BRMS
Hello, We have BRMS daily full system backups running, everything was smooth going on, however in last Month from 15th June backup is stretching day by day and now it s taking 1.40 minutes where it use to take only 50 minutes. I have checked everything i.e.libs counts,obj size,interfaces are also doubled checked and made schedule entries to end QZ prestart jobs, TCP host jobs and other applications as well. I also omitted qmpgdata from control group but this problem is not coming to end. Can someone please please help me out to find out the solutions? Thanks a ton Deepak Thapar
0

Answer Wiki

Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

Discuss This Question: 11  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • TheRealRaven
    Full-system backups every day??? Wow. On most systems, a full-system backup might be needed a couple times per year. Why would you need them daily?

    If you have the backup window available, you might as well do it, I suppose.

    We really can't help much. There are far too many possibilities for things that might be either becoming larger or becoming more numerous or simply causing backups to run longer. Inefficient authority assignments is an example of one thing that can cause backups to run long.

    The RTVDSKINF and RTVDIRINF commands would be used, perhaps once a week, to gather statistics on how many objects you have and what sizes they are. The PRTDSKINF and PRTDIRINF commands would report on those statistics. If you are gathering statistics, then you should compare week to week to see where the changes are.

    If you aren't gathering statistics, it's hard to guess were any trouble might be. There might not be any trouble at all. It might be that your current times are what they should be.
    34,465 pointsBadges:
    report
  • azohawk

    We had an issue a year ago where we had a similar issue (we do nightly full system backup also) where we were exceeding our allowed back-up window. Found thousands of log files in the IFS going back 5 years. Deleted them and cut 20 minutes off our our backups. Since then I have been keeping up with cleaning out journal recievers every few weeks, deleted some un-needed libraries and a few other clean-ups and chopped about 8 more minutes off. (I still think we have far to many items in the IFS, but not being familiar with most of them, I tend to leave them alone...)

    Since our issue last year, I have been tracking our back ups and have noticed that adding PTFs adds time. Even after we apply the PTFs and delete the delivery files the time needed for the back up is a little longer (1/2 minute or so) than before we loaded the PTF onto our system.  With the tracking I have been doing, I can easily see if something is out of norms before it gets to be a huge issue.

    But I have to agree w/ Raven that there are far to many possibilities for us give you solid answer. All we can do is give ideas of things to look for that we have found in the past.  

    A couple of other things you might want to look at: Has your disk utilization increased significantly? Do you have someone new making lots of duplicate files for testing/just in case backups? Someone leave that was maybe manually cleaning up something on a regular basis that is no longer being done (i.e. journal recievers, workfiles)?  An automated clean-up process that was removed, inactivated, damaged, changed? Is it actually that back-up that is increasing-could it be jobs that are refusing to end so the system can go to a restricted state to do the full system bu?

    Since I have statistics, I know that my system should be in a restricted state inside a two minute window (there are some variables that affect this). After restricted state, the first back up completes w/in 30 seconds, individual library backups start about 7.5 minutes later.  I know that the first back-up after IPL (which we do weekly) takes about a minute longer than the rest of the week, I know the IFS takes about 25 minutes to complete. I don't measure every library, but a sampling of about a dozen significant libs that  have a few minutes between each other. There may be a better approach than mine, but I have data that I know when something is not normal.

    4,055 pointsBadges:
    report
  • TheRealRaven
    "Even after we apply the PTFs and delete the delivery files..."

    On a side note for others, that should be done by first running APYPTF ... APY(*PERM) after the PTFs are accepted. Any delivery savefiles would be deleted with the usual DLTF.

    But more to the point, logfiles in a directory are good examples of sometimes hidden objects. They're good to mention. Various system services like web servers create logfiles nowadays, and they aren't always watched. That's why RTVDIRINF and PRTDIRINF should be added to RTVDSKINF procedures.

    If numerous relatively small streamfiles (or QSYS.LIB objects) are being created, they can take up much more backup time and space than fewer large objects. Each one must be accessed, stored on backup media possibly with gaps between, have ownership/authorities determined and saved, and then of course saved themselves.

    Details like those are why searching out large objects might not give good results in managing backups for a lot of sites.
    34,465 pointsBadges:
    report
  • azohawk

    In our most recent situaiton it was the image catalogues, but I have witnessed savf for PTFs hanging around even after a couple of cumes were applied.

    Which is another couple of items to look for: PTF's being loaded but not applied, accumulation other savefiles.

    4,055 pointsBadges:
    report
  • TheRealRaven
    Yes, the initial PTF savefiles won't go away until someone deletes them with DLTF.
    34,465 pointsBadges:
    report
  • deepakt1

    Hi,

    After last IPL, I see there's no big changes in system asp however my system is just 350 GB and 33% used. We also have the tool STGINF to retrieve prtdskinf but I have not found big deleted records which can be reorg.

    175 pointsBadges:
    report
  • TheRealRaven
    So far, there is no reason to think a large number of deleted records has anything to do with your problem. There shouldn't be any sites where deleted records are any problem at all.
    34,465 pointsBadges:
    report
  • deepakt1

    I checked into system no new installation has been done from last IPL. Eventually, all users are been revoked during the backup windows from any or all the interfaces, no disk size increased, no big logs found in system. I can't take parallel backups since we don't have enough new tapes and it would be subject to cost as well.

    However, daily is the full system save and if we omit savsecdta or savcfgdta it should shrink the timing but I'm still looking for some other alternatives.

    Thanks & Regards,

    Deepak Thapar

    175 pointsBadges:
    report
  • TheRealRaven
    You can't "omit savsecdta or savcfgdta" from a full-system save unless you have written your own (or BRMS has a customized version somehow). The SAVSECDTA and SAVCFG commands are intended as periodic save elements when not doing full-system saves. Can you clarify what your save is doing?
    34,465 pointsBadges:
    report
  • pdraebel
    I think your issues originate from the IFS combined with private authorities to the objects in the IFS. Please check your logs to verify SAVSECDTA times. If those are the main source of your increased Backup Times you will have to take  a closer look at IFS and private authorities.
    7,545 pointsBadges:
    report
  • deepakt1

    Hi,

     

    THanks for your valuable responses, i have changed the sequence of backup items ,all user data is brought to first backed up and sebsequently others would be saved. this has resolve the problem since  when user libraries are saved first and if other routine jobs takes  time which doesnt hold the work of user.

    175 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.

Following

Share this item with your network: