Sorry just read that and discovered that I missed a question. My answer 3
in the original response should be 4
3) This is the same answer as two. There become diminishing returns really
quickly inside a VTL to use any movement at all.
--
Jim Oberholtzer
Agile Technology Architects
-----Original Message-----
From: Jim Oberholtzer [mailto:midrangel@xxxxxxxxxxxxxxxxx]
Sent: Wednesday, July 20, 2016 3:54 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Backup to DISK using BRMS
Paul:
I'll answer for what we tell our BRMS customers with VTL units (Rob of
course will respond with what he does):
1) No, there is no need to since the file size of the volume on disk is
what's needed, not the full size of the tape. So if you only save 100Mb
then that's all the bigger the save is, unlike an LTO tape which would be a
massive waste of tapes. Keep in mind that most VTLs do significant
compression/compaction and some even have De-Dupe built in as well, so that
100Mb file will be significantly smaller once it is actually saved.
2) Some do use move policies but it's rapidly diminishing since there really
is no need. The exception comes when the customer will export a virtual tape
to a physical one and move it to offsite storage.
4) A VTL volume is treated no differently than tape, so yes it is ready for
use once BRMS expires the tape and all the files on the tape. (same as a
physical tape)
Another point: Most VTLs come with some level of encryption built in as
well. The tape image is encrypted at the VTL so it's even after the
compaction/compression/De-Dupe process. If that VTL is then replicated to
another location on a similar VTL, as long as the encryption keys are
available the remote unit can read the tape image and do whatever is needed,
so the data is encrypted at rest. That's big with the auditors nowadays.
--
Jim Oberholtzer
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Steinmetz, Paul
Sent: Wednesday, July 20, 2016 3:39 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Backup to DISK using BRMS
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
--
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.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
midrange.com
