One thought about your last comment "can be restored in a pinch" when the
tape is expired. Depending on how you have the BRMS maintenance set up the
BRMS database may no longer have the records of what's on that tape so any
restore would need to be done old school, as opposed to using BRMS to do the
restore for you.
--
Jim Oberholtzer
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Rob
Berendt
Sent: Thursday, July 21, 2016 6:10 AM
To: Midrange Systems Technical Discussion
Subject: RE: Backup to DISK using BRMS
1) Do you append?
No. Never did, and, with vtl, why would you want to?
2) Do you still use move policies?
No. I no longer use move policies since moving to vtl.
3) No need to run movement, correct?
Correct. The tapes stay in the media library. The replication to the other
Data Domain is outside of BRMS. And it keeps the same volume name.
4) When a VTL volume expires, is it automatically ready to be used for a
future save.
Yes. Some have already been reused. BRMS has a preference system on
volumes. First it looks for ones that have never been used. So if you
create 400 tapes you will use all those before it starts taking expired
tapes. Then it looks for tapes that have been expired the longest. The
theory there being that, even though the tape is expired the data is still
there and can be restored from in a pinch.
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: 07/20/2016 04:39 PM
Subject: RE: Backup to DISK using BRMS
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
Rob,
1) Do you append?
2) Do you still use move policies?
3) No need to run movement, correct?
4) When a VTL volume expires, is it automatically ready to be used for a
future save.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Rob
Berendt
Sent: Tuesday, July 19, 2016 4:22 PM
To: Midrange Systems Technical Discussion
Subject: RE: Backup to DISK using BRMS
On the same VTL the tapes would not have to be shifted. For example, in
Garrett, with 10 lpars on the same VTL we could save on GDIHQ (prod) and
restore on to GDISYS (dev) by running this command:
RSTLIBBRM SAVLIB(ERPLXF) DEV(GRRTVTL) SAVLVL(*CURRENT) MBROPT(*ALL)
ALWOBJDIF(*ALL) FROMSYS(GDIHQ)
if you have three saves of ERPLXF, all done on GDIHQ it will know to use
the most current save by the SAVLVL(*CURRENT)
Here it would be a little different though. We normally do our saves in
Kendallville on the Mimix replicas. So a save done on GDIHQ2 would be
restored to GDISYS2. The only trick being that normally Mimix replicates
from GDISYS to GDISYS2 so you would have to handle that.
I believe we often shutdown that part of Mimix during such a 'refresh' to
avoid really flooding the journals. Darren (also on this list) normally
handles our refreshing.
The only shifting would be if one just insisted on the save on GDIHQ2 in
Kendallville being restored on to GDISYS in Garrett.
Now, this may be able to be done via scripting. I'm more used to using
the GUI interface of the library but the die hards who connect in remotely
to assist us use the Command Line Interface. There are a few occasions in
which I've noticed some different behavior based on whether or not one
used the GUI or the CLI to perform the task. I do think if more of the
diehards used the GUI then it would have some more of these differences
ironed out.
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: 07/19/2016 03:47 PM
Subject: RE: Backup to DISK using BRMS
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
Rob,
How would this work using a VTL, 2 LPARS.
22:00 - Production nightly save.
02:00 - On R&D RSTLIBBRM from 22:00 Production nightly save.
Would tapes have be shifted?
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Rob
Berendt
Sent: Tuesday, July 19, 2016 3:26 PM
To: Midrange Systems Technical Discussion
Subject: Re: Backup to DISK using BRMS
About the only time I can think we may need a physical is to send to IBM
for restoration there for certain special situations.
Our DD2500's are set up with a couple of pools of tapes.
Our Kendallville one has
- kdvl-vtl for the 'tapes' used on it
- grrt-vtl-dr for the tapes used on the Garrett vtl Our Garrett one has
- grrt-vtl for the tapes used on it
- kdvl-vtl-dr for the tapes used on the Kendallville vtl
I can be doing backups to both at the same time. The pools are replicated
between each other. I have to shift tapes from one pool to the other if I
want to restore Garrett data in Kendallville (or vice versa). When you do
that the tape becomes a 'read only' while in that pool. Which kind of
makes sense.
It sounds to me like you are trying to get them to both appear as TAPMLB01
or some similar fashion on the same machine. If that's the case, I can
see why you would have to vary one off to vary the other on.
Here, we only ever see one of the libraries. All the Kendallville lpars
see KDVLVTL and all the Garrett lpars see GRRTVTL. But, as I said before,
we can 'move' the tapes to do a remote restore.
Sure beats driving the tape over or waiting for an Iron Mountain delivery.
When we were first banging out DUPMEDBRM and our first backups the boss
could really notice it on the comm when the replication was kicking in.
Now he keeps asking us if were done even though we have some intensive
DUPMEDBRM (four lpars at once) going on. Probably due to there being more
data in the deduping to select from.
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: Marc Rauzier <marc.rauzier@xxxxxxxxx>
To: midrange-l@xxxxxxxxxxxx
Date: 07/19/2016 02:44 PM
Subject: Re: Backup to DISK using BRMS
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
Le 19/07/2016 à 19:52, Rob Berendt a écrit :
Couldn't you do a DUPMEDBRM from one VTL volume to another VTL volume?
This way they would be on two separate volumes?
Our two VTLs are configured as a backup of each other. The replication
is managed by the VTL so that the media are put on virtual shelves. For
a given partition, both VTL are configured but only one is varied on at
the same time. In case of a failure on the varied on/active VTL, we have
to vary it off [to avoid the partition to be aware of two medias with
the same name, which is not good], vary on the backup one, through the
VTL interface move the media from the shelves to the virtual library
slots, and, through BRMS move them from the location related to the
failing VTL to the newly varied on VTL.
The replication is running on both ways. If we would run DUPMEDBRM
from/to VTL, we would have in fact 4 times the same save.
On another side, we have to keep the physical tape library as we do not
want to use the VTL for media with a long term retention (for example
with a 10 years retention). For this reason, I have to check with the
architect what was the idea to do so, but if I remember fine, keeping
those media would decrease the deduplication ratio. So, as we have to
keep the physical library, we use them.
By the way the VTL are used by all our customers but only one or two
require duplications. And, I have also to check, they required at least
one physical media to agree using our VTL implementation. We have had a
lot of troubles to convince them (and all others, in fact) to switch
from physical to virtual libraries.
Marc
midrange.com
