BRMS Backup Strategy and Implementation -- MIDRANGE-L

Rob,

We also have a good fiber network, 9,000 miles in NE PA. The issue is that the tape libraries are fiber channel, which is very limited for distance. The network folks were reviewing the options, long distance fiber channel transmitters or convert fiber channel to Ethernet, both solutions were pricey, project went on hold. We have a colo that was close, but from a DR respective, too close.
I was going replace my current LTO 5 with a LTO 6 library, move the LTO5 to a new site tbd. Or pursue a DEDUP device. I'm not comfortable with DEDUP device, not sure it will be able to achieve everything we do with tape. We restore a copy of production weekly to any of 6 copies on R&D.

Paul

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Wednesday, February 05, 2014 4:45 PM
To: Midrange Systems Technical Discussion
Subject: RE: BRMS Backup Strategy and Implementation

We have a pretty good network structure. For example we have Mimix running between two cities and that has good bandwidth. Only 17 miles and a lot of new fiber we're piggybacking on.
I forget the exact product name (I was just told to fill out the sizing worksheets). Some sort of VTL. One here, one there, one in the cloud.

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/05/2014 04:28 PM
Subject: RE: BRMS Backup Strategy and Implementation
Sent by: midrange-l-bounces@xxxxxxxxxxxx

Which solution, DEDUP or 2nd Tape Library.
I think the networking cost exceeded the cost of the 2nd device.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Wednesday, February 05, 2014 4:23 PM
To: Midrange Systems Technical Discussion
Subject: RE: BRMS Backup Strategy and Implementation

Apparently there's a lot of people doing that.
My boss seriously looked at that. We even got to the point of filling out
the sizing sheets, etc. However the sticker shock stunned him.

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/05/2014 03:53 PM
Subject: RE: BRMS Backup Strategy and Implementation
Sent by: midrange-l-bounces@xxxxxxxxxxxx

Next step, customize the BRMS recovery report
Researching the new DEDUP devices or a 2nd off site tape library.
If implemented, no tape handling at all, all volumes would remain in both
libraries.
This would be sweet.

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

The many lpars to one volume may make sense if:
- You are not doing any SAVSYS
- You have a large enough window of save.

For example, with a fiber option SAN switch and each lpar having their own
connection to it and multiple tape drives in our tape library we can back
up multiple lpars at once. Limited mainly by the number of tape drives in
the library. Saving many lpars to one tape volume would require some
coordination.
But I could see where only sending one tape to Iron Mountain instead of
five every day would significantly reduce the number of tape volumes
required. Instead of
14 levels of retention by 5 daily tapes,
6 levels of retention by 5 weekly saves
We could cut that down by perhaps 1/5th.

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/05/2014 03:05 PM
Subject: RE: BRMS Backup Strategy and Implementation
Sent by: midrange-l-bounces@xxxxxxxxxxxx

Rob,

I agree, keep it simple stupid.
If I could simplify, I would.
The point I was trying to make is you can still have all volumes in one
pool, yet BRMS can keep saves separate, if needed.
BRMS is scary when you first see it, I didn't know where to start.
It would nice if you could save to the same volume from various LPARS, but
that will never happen.
Also, DUPMEDBRM needs a major overhaul from a performance standpoint.
Finally, BRMS recoveries still scare me, I'm still testing, when I have
time.
A restore 21 was always so much simpler and easier.

Paul

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Wednesday, February 05, 2014 8:47 AM
To: Midrange Systems Technical Discussion
Subject: RE: BRMS Backup Strategy and Implementation

I don't understand your setup. But it's not important that I do.
I don't think the average BRMS shop needs to be nearly as complex.
Maybe yours does.
Hey, if it works for you.
I just don't want to scare other BRMS users.

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 04:30 PM
Subject: RE: BRMS Backup Strategy and Implementation
Sent by: midrange-l-bounces@xxxxxxxxxxxx

Rob,

Sorry I couldn't explain it better. But it actually works all
automatically once setup.
The setup was a little intense, but the automation was worth it.
Here's the all move/media policies that make it all work.
Basically a separate policy for each save and dup.

APPEND10D Pencor06 Daily Chobs DUP
APPEND45 Pencor06 Daily Chobs
CYCBRC35D Pencor05 BRC Cycle DUP
CYCBRC396 Pencor05 BRC Cycle
DAILY10D Pencor05 Daily Full DUP
DAILY45 Pencor05 Daily Full
PERMBRC Cable ICOMS M/E
PERMBRCAUD Cable ICOMS M/E
PERMBRCD Cable ICOMS M/E
PERMPTC Telephone Billing/Cabs/Toll Purge
PERMPTCD Telephone Billing/Cabs/Toll Purge
PERM05 PERM05
PERM06 PERM06
PERM06D PERM06
SAVSYS05 Pencor05 system save
SAVSYS05D Pencor05 system save
SAVSYS06 Pencor06 System save
SAVSYS06D Pencor06 System save
TNCORPERM TN Correspondants
TNCOR35D TN Correspondants DUP

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

We do very limited append. We have maybe two tapes total that are
'permanent'. These are year end saves of two archive libraries. We did
have to put them into their own pool. (Hey, you're starting to sink
in...) Putting them into their own 'media class' was really the only way
to ensure that it appended on to the right tape. SAVLIBBRM doesn't allow
you to specify a volume id.

We do not dup any saves. I can see the advantage of that. Send a copy
offsite and keep a copy on site. Therefore you don't have the delay of
getting the tape back when doing a restore. That's one reason why many
people are going to virtual tape libraries. Actually we do dupe that year
end archive. But that's not for local/remote. That's because it's the
only copy and we don't want the risk of one tape going bad.

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 02:29 PM
Subject: RE: BRMS Backup Strategy and Implementation
Sent by: midrange-l-bounces@xxxxxxxxxxxx

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

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

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

--
Gord Hutchinson
TST Overland Express
--
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.

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

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