RE: BRMS Backup Strategy and Implementation

["Steinmetz, Paul" <PSteinmetz@xxxxxxxxxx>]

Rob,

Do you use append?
Do you dup all your saves?

We don't want perm saves mixed with saves that expire, etc.
Still using all one scratch pool, when a volume becomes active the media/move policy for that save/control group is assigned to that volume, then only the same save will be appended to that volume.
Prior to doing this, when our saves expired, we ended up with many volumes with only a few items on them, so the volume would never expire.
That's our reasoning.

Paul

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Tuesday, February 04, 2014 1:46 PM
To: Midrange Systems Technical Discussion
Subject: Re: BRMS Backup Strategy and Implementation

Yeah, too many people try to use BRMS to duplicate their old way of thinking, with meaningful tape volume names, etc.

As I said ealier, I also don't allocate tapes to different retentions.  It grabs a tape from the library and assigns it the retention I want for this backup.

WRKPCYBRM contains items like
Policy  Days to retain media
MONDAY  35
DTFULL  360
TUE_FRI 14

WRKJOBSCDE 
                    -----Schedule------
Job         Status  Date       Time 
BRMBKUP      SCD    USER DEF   17:30:00
BRMBKUPMON   SCD    *MON       17:30:00

BRMBKUP
Command  . . . . . . . . . . . :   STRBKUBRM CTLGRP(TUE_FRI) SBMJOB(*NO)

BRMBKUPMON
Command  . . . . . . . . . . . :   STRBKUBRM CTLGRP(MONDAY) SBMJOB(*NO)

WRKCTLGBRM
             Full 
 Control     Media 
 Group       Policy 
 
 *BKUGRP     *BKUPCY
 *SYSGRP     SAVSYS 
 *SYSTEM     SYSTEM 
 DTEXTRA     DTEXTRA
 DTFULL      DTFULL 
 MONDAY      MONDAY 
 OMTCPY      *BKUPCY
 TUE_FRI     TUE_FRI
...
Group  . . . . . . . . . . . . . . . . : MONDAY Media policy for: 
  Full backups . . . . . . . . . . . . . MONDAY
  Incremental backups  . . . . . . . . . MONDAY Backup devices . . . . . . . . . . . . . *BKUPCY ...


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to:  2505 Dekko Drive
          Garrett, IN 46738
Ship to:  Dock 108
          6928N 400E
          Kendallville, IN 46755
http://www.dekko.com





From:   Gord Hutchinson <gordm1@xxxxxxxxxxxxxxx>
To:     Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date:   02/04/2014 12:38 PM
Subject:        Re: BRMS Backup Strategy and Implementation
Sent by:        midrange-l-bounces@xxxxxxxxxxxx



Rob,

I was happy to see your comments about pulling tapes from one big pool.

I need to set up BRMS here as well.  I wanted to have one tape pool across
two lpars and different types of save. I was told by a BP that I needed to
allocate tapes to specific save pools (for want of a better word).  i.e.
These tapes are for Monday's development save, these are Monday's
production and so on.

I'm glad I can go back to my original 'vision'.


Gord





On Tue, Feb 4, 2014 at 10:54 AM, <rob@xxxxxxxxx> wrote:

> We also have different retention policies.  Monday is kept for 'weeks'.
> Other days for 'days'.  Quarterly for a year.
> We don't care if BR0204 expires off of a daily save and gets used in a
> Monday or Quarterly save.  Makes no difference to us.  WRKMEDBRM will 
show
> us when the tape was used and when it will expire.  WRKOBJBRM will show 
us
> what tapes it was saved on and when.
>
>
> Rob Berendt
> --
> IBM Certified System Administrator - IBM i 6.1
> Group Dekko
> Dept 1600
> Mail to:  2505 Dekko Drive
>           Garrett, IN 46738
> Ship to:  Dock 108
>           6928N 400E
>           Kendallville, IN 46755
> http://www.dekko.com
>
>
>
>
>
> From:   "Steinmetz, Paul" <PSteinmetz@xxxxxxxxxx>
> To:     "'Midrange Systems Technical Discussion'"
> <midrange-l@xxxxxxxxxxxx>
> Date:   02/04/2014 10:49 AM
> Subject:        RE: BRMS Backup Strategy and Implementation
> Sent by:        midrange-l-bounces@xxxxxxxxxxxx
>
>
>
> Rob,
>
> Sorry for the confusion, currently only 6 scratch volumes, but normally
> about 14.
> Currently redoing a 10 year, 4 volume dup.
> Our library has 45 slots, 1 reserved for cleaning,  3 I/O slots.
> Currently 34 active volumes, probably about 10 different saves/control
> groups.
> We keep the this many active volumes in the library, most restores don't
> require a media load, already in the library.
> We run saves every day also, some saves have different retentions, so 
the
> combination of move/media policy will save/append to the correct volume.
> We load / unload M-F.
> I want to keep them balanced.
> It's not really tricky the system, but keeping like saves on the same
> volumes.
>
> Paul
>
> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx [
> mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
> Sent: Tuesday, February 04, 2014 10:29 AM
> To: Midrange Systems Technical Discussion
> Subject: RE: BRMS Backup Strategy and Implementation
>
> Only 6 volumes total?  How many does your library hold?
> Our library holds over 50 volumes.  We load up a weeks worth at a time.
> Actually 6 'run' days.  We back up 5 days a week.  The advantage to this
> is it will still back up when the office is closed due to holidays or 
snow
> emergencies.  Our library also has 18 I/O slots but don't let the number
> of I/O slots limit you.  We only run the *BALANCE once a week.  Yes, we
> remove the daily tapes every day but we only load new tapes once a week.
>
> If you really are truly limited to 6 volumes, and you want two for one 
and
> 4 for the other, then you should run the *SETs separately.  One for 2 
and
> one for 4.  But if your library holds a weeks worth then do a *SET for 
(5
> * 2) for the one and (5 * 4) for the other.  Replace 5 by the number of
> days of the week you back up.
>
> You're not still trying to trick the system to use certain volumes on
> certain days of the week, are you?
>
>
> Rob Berendt
> --
> IBM Certified System Administrator - IBM i 6.1
> Group Dekko
> Dept 1600
> Mail to:  2505 Dekko Drive
>           Garrett, IN 46738
> Ship to:  Dock 108
>           6928N 400E
>           Kendallville, IN 46755
> http://www.dekko.com
>
>
>
>
>
> From:   "Steinmetz, Paul" <PSteinmetz@xxxxxxxxxx>
> To:     "'Midrange Systems Technical Discussion'"
> <midrange-l@xxxxxxxxxxxx>
> Date:   02/04/2014 10:03 AM
> Subject:        RE: BRMS Backup Strategy and Implementation
> Sent by:        midrange-l-bounces@xxxxxxxxxxxx
>
>
>
> Rob,
>
> To keep 2 LPARs balanced with the same number of owned scratch volumes,
> would the below be the correct STRBALBRM strategy.
>
> Currently Pencor05 owns 2 scratch ULTRIUM5 volumes, Pencor06 owns 4
> scratch ULTRIUM5 volumes.
>
> First, only once I would run
> QSYS/STRBALBRM ACTION(*SET) MEDCLS(ULTRIUM5) LOC(TAPMLB01)
> SYSNAME(PENCOR05 PENCOR06) MEDREQ(6)
>
> Then daily, after loading scratch volumes into TAPMLB01,  I would run
> QSYS/STRBALBRM ACTION(*BALANCE) MEDCLS(ULTRIUM5) LOC(TAPMLB01)
> SYSNAME(PENCOR05 PENCOR06)
>
> Paul
>
>
>
> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx [
> mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
> Sent: Tuesday, February 04, 2014 9:19 AM
> To: Midrange Systems Technical Discussion
> Subject: RE: BRMS Backup Strategy and Implementation
>
> And you only run STRBALBRM on one system.  Or how you like to run it.
>
> For example, if we have one tape library used in our Garrett IN office,
> and that feeds multiple lpars, we may run the STRBALBRM on one of the
> lpars there.  And run a different STRBALBRM, once, on one of other lpars
> in our Kendallville IN office for all of the lpars there.
>
>
> Rob Berendt
> --
> IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 
Mail
> to:  2505 Dekko Drive
>           Garrett, IN 46738
> Ship to:  Dock 108
>           6928N 400E
>           Kendallville, IN 46755
> http://www.dekko.com
>
> --
> 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 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 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.