With our VTL's the saves occur locally. If you do a SAVLIB on a 1TB library it will not take 1TB of space on the VTL. Now, will it transfer the whole 1TB of data to the VTL and let it do the dedup? Yes. So, let's say you get a 50-1 dedup. BRMS sends down your 1TB of data. The VTL does it's dedup and saves 20GB on the local VTL. The VTL then sends this 20GB to the remote VTL as a backup. Remember, BRMS is not doing the dedup, the VTL is.
Why concern yourself with whether or not the save expires the whole tape or just one sequence on the tape? Each tape should have the same expiration interval for all of it's sequence numbers.
This is not like physical tape. With physical tape 4TB takes up x number of feet of mylar. With a VTL when I configure 300 4TB tapes it does not immediately tie up 1200 TB of space on the VTL. They are just place holders. The odds of it ever taking 1200 TB are slim to none, even if you try to save 1.2PB on your first initial save. It does keep track intelligently enough so that if you do a DUPMEDBRM from a VTL tape to a physical tape it should be pretty much a one to one provided you configure them to a size of the same between the VTL tapes and the physical tapes.
With physical tapes you play games like "gee, I have a 4TB tape which costs me $xxx/each". So you may try to fill it up before you send it offsite. You may even end up with different sequences having different expiration dates. With a VTL you simply do not care. You're not wasting any mylar or disk space
VTL's are a HUGE liberator!
Exercise:
On the first of every month we save our journal receivers on our big production machine. We're journal receiver nuts and do a lot of analysis on them. Receivers take up about 3 times as much space as our data files. IBM thinks we're crazy but the check clears for the disk space.
PRTDSKINF RPTTYPE(*LIB)
Library Owner Disk 1000 bytes
#MXJRN ROB 27.58 2159378706.4
ERPLXF SSA 10.46 818905460.7
Evidently we filled up a tape, which at 2.1TB for #MXJRN makes sense. I configured by VTL tape size to be 1.5TB to mimic a LTO5 tape in case we ever wanted to do DUPMEDBRM back to mylar.
WRKMEDBRM TYPE(*ACT) SLTCRTDATE(010120) SYSNAME(*LCL) SORT(*CRT)
Volume Creation Expiration
Serial Status Date Date Location
G00245 + *ACT 01/01/20 12/31/20 KDVLVTL
G00281 + *ACT 01/01/20 12/31/20 KDVLVTL
It starting saving on G00281, filled that and went on to G00245.
Now if you look at the image at:
https://imgur.com/CleeZF2
You will see that it 'filled' up the first 1500GB tape (G00281) However it doesn't take 1.5TB of space on the VTL as it got 56x compression. The second tape used up what would have been 64% of mylar but it got 31x compression. Would have been nice in the mylar days to know exactly how full they were! But it's nicer to not care anymore!
Oh, and look at this. Let's say I want to restore receiver ALLRCV1292.
WRKOBJBRM OBJ(#MXJRN/ALLRCV1292) OBJTYPE(*ALL) SLTDATE(120119)
Now I just pick the one I want with option 7 and it restores it.
Of course, if I was still using physical tape I would have to call Iron Mountain and request that tape back, or just pick one which was at our current location. There's a location column which is not shown. With Iron Mountain we gave the users the choice of restoring from one on site, waiting for a tape to return from rotation (no permanent tapes), requesting one back from Iron Mountain the next day (if ordered in time), or calling Iron Mountain for a rush shipment. We only did the rush once and it was an abysmal failure.
Save Save
Object Library Type Date Time Volume
ALLRCV1292 #MXJRN *JRNRCV 12/01/19 19:31:15 G00284
ALLRCV1292 #MXJRN *JRNRCV 12/14/19 8:15:39 G00243
ALLRCV1292 #MXJRN *JRNRCV 1/01/20 19:31:12 G00281
This is the kind of stuff which frees you up from having to come up with cute volume names based on day of the week, lpar name, etc. Been there, done that.
Rob Berendt
midrange.com
