On 2/22/2013 1:08 PM, Skip Robinson wrote:
The biggest advantage of large volumes is reduction in UCB count. One
disadvantage is that larger volumes take longer to back up and to restore.
We have some astonishingly large 'volumes' in the open systems world that
are supported by only modestly fast backup/restore processes. Keeping an
important application down for a lengthy restore is a hard bullet to bite.
Backup/restore times are definitely longer for large volumes. Having
said that, our overall backup/dump times did not change after we
consolidated many small volumes (mod3s, 6s, and 9s) onto fewer larger
ones (mod27s, 54s, 81s, etc.).
We need to a) every day incrementally backup 'n' changed tracks onto 'm'
tape drives and b) periodically dump 'x' volumes onto 'y' tape drives
where we stack multiple dumps onto high-capacity tapes. We have no VTS.
No matter how we distribute the data among our DASD volumes (small,
medium, large, extra-large), we never realize more than a few minutes of
variability in overall backup or dump times.
It seems that to appreciably reduce overall backup/dump time (without a
radical hardware technology change) we can 1) purchase more tape drives,
2) update fewer DASD tracks every day (affects daily backups only), or
3) stop backing up or dumping some volumes.
One area of focus is our corporate file server, which utilizes the
DFS/SMB server on z/OS. We have large, single-volume ZFS data sets on
large volumes. (They used to be multivolume ZFS on smaller volumes). One
small update causes the entire ZFS to require daily HSM backup. That can
be a time-consuming process. For example:
ARC0722I BACKUP STARTING ON VOLUME LAN01 (SMS) AT 340
ARC0722I (CONT.) 02:36:48 ON 2013/02/23 SYSTEM MV60
...
ARC0723I BACKUP ENDING ON VOLUME LAN01 AT 04:37:58, 318
ARC0723I (CONT.) 00000001 DATA SETS BACKED UP
We do daily incremental backups of this data using Tivoli Storage
Manager (The TSM 5.3 client runs under OMVS; the TSM 6.2 server runs on
Linux for z). I'm tempted to stop backing up the physical ZFS altogether
via HSM and rely 100% on the Tivoli backups. But, I'm hesitant to do so.
We have never before excluded important volumes from our HSM backup/dump
process. I'm curious what others would do in a similar situation...
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
