Re: BRMS Backup Strategy and Implementation -- MIDRANGE-L

You, Rob? Not follow a recommendation? :)

Yes, it is recommended to store the .nlo's outside of the data directory.
Also, when deciding on the minimum file size for DAOS always error on the
side of going too big rather than too small. It is a quick and easy
change to go smaller later on. It is painful to go the other way. Also,
the more files you have in the IFS the slower it will be for backup and
recovery. Best advice - you want to be talking thousands of .nlo files
not millions of .nlo files. Once you get 2 million .nlos for a single
Domino partition performance goes away real fast and not just for BRMS.

Amy Hoerle
System Administrator
Think Mutual Bank
5200 Members Pkwy NW, Box 5949
Rochester, MN 55901

507-536-5815 or
800-288-3425 Ext 5815
ahoerle@xxxxxxxxxxxxx

From: rob@xxxxxxxxx
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 02/11/2014 08:44 AM
Subject: Re: BRMS Backup Strategy and Implementation
Sent by: midrange-l-bounces@xxxxxxxxxxxx

--------------------------------------------------------------------------

Good points Amy.
Not that I've been known to follow any recommendations but isn't it also
recommended to store .nlo's somewhere else also?

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
[1]http://www.dekko.com

From: AHoerle@xxxxxxxxxxxxx
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>,
LRoberts@xxxxxxxxxxxxxxx
Date: 02/11/2014 08:52 AM
Subject: Re: BRMS Backup Strategy and Implementation
Sent by: midrange-l-bounces@xxxxxxxxxxxx

Hi Laura,

It looks like most of your questions were answered. I'll just add a
few
thoughts about BRMS and Domino. I would say most people started
switching
to using BRMS to back up their Domino servers about 10 years ago. It
does
a nice job and if you implement incremental saves you can even get
point
in time recovery for your Domino .nsf files. Setting up incremental
BRMS
saves is rather tricky so if you want to go that route I'd be happy to
give you some additional advice or documentation that would help. (The
rule of thumb for simple point in time backups and recovery - save the
server twice each night - incremental first, then a full).

A few thoughts about backing up Domino online:

It is very nice that you don't have to bring your server down. However;
It does not save everything. BRMS online saves will save .ns*, .nt*,
.box
and .nlo files (if you have implemented DAOS and have a recent BRMS and
Domino level). What is it not saving? the basic config files that
shouldn't change on a regular basis (notes.ini, server.id, ssl cert,
etc).
On my systems I take the servers down and do a full save of the data
directory before each Domino upgrade in addition to a year end save.
Other than that, I do not worry about saving the other files because
they
should not be changing.

A word of caution that can save you pain that many have experienced: Do
not ever end a BRMS Domino save using the ENDJOB command. It will
crash
the Domino server it is currently saving.

Where people run into the most trouble with BRMS and Domino is saves
that
touch files that Domino doesn't want you to be locking while it is up
and
running. Not saving the Domino data directory (other than in a control
group with the SAVDOMBRM command) is obvious. What isn't so obvious is
some of the other IFS directories. Here is the list of files and
directories you want to be sure to save are not attempted to be saved
while the server is running:

/tmp (note that /tmp does not = /tmp/*. Omitting /tmp/* will not
work
as the directory itself should be omitted)
/qibm/proddata/lotus
/qibm/userdata/lotus
directory containing transaction logs if they are not under the
server's
data directory
directory containing view indexes if you are building and storing
indexes
outside of the server's data directory

There is a data area available to help you avoid this so reference
[1][2]http://www-01.ibm.com/support/docview.wss?uid=swg21404738 if you
have
questions and remember that *LNKOMTLTS is your friend.

Good luck with your BRMS configuration!

Amy Hoerle
System Administrator
Think Mutual Bank
5200 Members Pkwy NW, Box 5949
Rochester, MN 55901

507-536-5815 or
800-288-3425 Ext 5815
ahoerle@xxxxxxxxxxxxx

From: <LRoberts@xxxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion
<midrange-l@xxxxxxxxxxxx>
Date: 02/05/2014 12:53 PM
Subject: Re: BRMS Backup Strategy and Implementation
Sent by: midrange-l-bounces@xxxxxxxxxxxx

--------------------------------------------------------------------------

Thank you to everyone who gave me some insight in how you are using
BRMS.

I am wondering if most people using BRMS are taking advantage of the
save
while active and the Lotus Domino feature save while active ?

Does anymore have any pros and cons to using either ? Any things to
watch
out for or issues in restoring ?

We are doing our yearly DR test next month which we have proven
successful
in the past, but next year the plan for our DR test is to restore using
BRMS so will be a whole new ball game ......

Thanks again

Laura

From: Jerry Draper <midrangel@xxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion
<midrange-l@xxxxxxxxxxxx>,
Date: 03/02/2014 01:49 PM
Subject: Re: BRMS Backup Strategy and Implementation
Sent by: <midrange-l-bounces@xxxxxxxxxxxx>

This pretty much sums up our experience as well. I would heartily
endorse the idea of taking Rob's leap of faith in trusting BRMS and
getting rid of any kind of tape naming convention.

Jerry

On 2/3/2014 11:25 AM, rob@xxxxxxxxx wrote:
> First of all I would reinitialize all your tapes and get rid of the
> specific naming strategy. You are no longer looking at that. You
should
> only look at the BRMS reports and commands like WRKOBJBRM to see what
tape
> holds what. YOU have to take a leap of faith in technology. Would
you
> accept it if your users always kept manual inventory cards along with
the
> computer and relied upon the manual cards instead of the computer?
Eat
> your own cooking.
>
> We load up a weeks worth of tapes. Every morning we take out the
previous
> nights tapes and send those off to Iron Mountain. What comes back we
> store until the Monday load.
> We do have a different save for Monday nights. We retain Mondays for
6
> weeks. The daily's for only 14 days. The quarterly's for 1 year. We
set
> that up and track that in BRMS. We do NOT use spreadsheets, etc
tracking
> which tapes expire when.
>
> The network data is stored on ALL lpars. Lose one and you still have
your
> BRMS data.
>>From any system you can do a
> WRKMEDBRM SYSNAME(GDI1.GDIHQ)
> Volume Creation Expiration Move Media Dup
> Serial Status Date Date Location Date Class Sts
> BR0372 *ACT 12/14/13 12/09/14 IRONMTN 12/17/13 ULTRIUM4
> BR0394 *ACT 03/09/13 03/04/14 IRONMTN 05/20/13 ULTRIUM4
> BR0458 *ACT 06/08/13 06/03/14 IRONMTN 06/11/13 ULTRIUM4
> BR0514 *ACT 09/14/13 09/09/14 IRONMTN 09/23/13 ULTRIUM4
> ...
>
>
>>From ANY system I can do
> WRKOBJBRM OBJ(ERPLXF/IIM) OBJTYPE(*FILE) FROMSYS(GDI1.GDIHQ2)
> Save Save
> Opt Object Library Type Date Time Volume
> IIM ERPLXF *FILE 3/06/13 17:13:58 BR0363
> IIM ERPLXF *FILE 6/05/13 14:54:47 BR0519
> IIM ERPLXF *FILE 9/11/13 13:43:48 BR0432
> IIM ERPLXF *FILE 12/09/13 17:39:40 BR0329
> IIM ERPLXF *FILE 12/11/13 13:22:39 BR0306
> IIM ERPLXF *FILE 12/16/13 17:39:19 BR0300
> IIM ERPLXF *FILE 12/23/13 17:39:01 BR0407
> IIM ERPLXF *FILE 12/27/13 17:38:50 BR0304
> IIM ERPLXF *FILE 12/30/13 17:39:18 BR0369
> IIM ERPLXF *FILE 12/31/13 17:39:14 BR0313
> ...
>
> With this kind of tracking available having prefixes indicating which
tape
> holds what has absolutely no value. And it just complicates the hell
out
> of loading your media library.
>
> You might really benefit in your situation by having a consultant
come
in
> and help you set this up. They do a pretty good job of getting you
to
> think outside of your existing strategy. We used Sirius.
>
> We also use virtual tapes, (not save files).
> We have one system that we have offsite and we do not want to
physically
> handle tapes there. So we use BRMS to save to virtual tape. We FTP
the
> tape to a system here. Then we use DUPMEDBRM (notice the BRM
suffix?)
to
> duplicate it to physical tape. And I can still do the appropriate
> WRKOBJBRM and see which tape, virtual or physical, has the object in
> question. If you start trying to work around the system you'll lose
all
> that. If you can't handle the FTP scripts and what not IBM has a
tool
> that they'll gladly charge you for which will do the same thing for
> virtual tapes.
>
> I too thought our backup strategy was all oh so unique. And had to
do
all
> sorts of gyrated commands on the media library to get our named tapes
to
> work for the right system. And had long strings of CL and RPG
programs
> for performing backups. Fought BRMS for years. Now I am a strong
> advocate.
>
> Rob Berendt
>

--
Jerome Draper, Trilobyte Software Systems, since 1976
iSeries, Network, and Connectivity Specialists -- iSeries, LAN/WAN/VPN
Representing WinTronix, Synapse, Netopia, HiT, and others .....
(415) 457-3431; [2][3]www.trilosoft.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: [3][4]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 [4][5]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: [5][6]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 [6][7]http://archive.midrange.com/midrange-l.

References

Visible links
1. [8]http://www-01.ibm.com/support/docview.wss?uid=swg21404738
2. [9]file:///tmp/www.trilosoft.com
3. [10]http://lists.midrange.com/mailman/listinfo/midrange-l
4. [11]http://archive.midrange.com/midrange-l
5. [12]http://lists.midrange.com/mailman/listinfo/midrange-l
6. [13]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: [14]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 [15]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: [16]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 [17]http://archive.midrange.com/midrange-l.

References

Visible links
1. http://www.dekko.com/
2. http://www-01.ibm.com/support/docview.wss?uid=swg21404738
3. file:///tmp/www.trilosoft.com
4. http://lists.midrange.com/mailman/listinfo/midrange-l
5. http://archive.midrange.com/midrange-l
6. http://lists.midrange.com/mailman/listinfo/midrange-l
7. http://archive.midrange.com/midrange-l
8. http://www-01.ibm.com/support/docview.wss?uid=swg21404738
9. file:///tmp/www.trilosoft.com
10. http://lists.midrange.com/mailman/listinfo/midrange-l
11. http://archive.midrange.com/midrange-l
12. http://lists.midrange.com/mailman/listinfo/midrange-l
13. http://archive.midrange.com/midrange-l
14. http://lists.midrange.com/mailman/listinfo/midrange-l
15. http://archive.midrange.com/midrange-l
16. http://lists.midrange.com/mailman/listinfo/midrange-l
17. http://archive.midrange.com/midrange-l