>> On Mon, 22 Jan 2007 14:20:56 -0500, Anker Lerret <ADSM-L AT LERRET DOT US>
>> said:
> Wow! What a massive outlay of effort. I'm not familiar with virtual
> volumes. If your problem is specific to them, then what I have to say is
> way off base, in which case I apologize in advance.
Don't apologise for working to give good advice. :)
> First, I do BACKUP STORAGE POOLs hourly from my *disk* pools. This gets
> most of my data out to the copy pools without having to mount a bazillion
> tapes to collocate and then re-mount them for the uncollocated copy pools.
> I only do migrates twice a day for each storage pool. Occasionally a
> disk pool will fill and migrate itself, but c'est la vie.
Agreed. You sound like your infrastructure is more steady-state than
mine. 90% of my daily workload comes in between 1700 and 2300, so I
don't do copies hourly.
> Second, I understand that it's possible to assign one or more
> COPYSTGPOOLS to a storage pool, which will cause it to mount the
> copy pool tapes whenever (with certain exceptions, so you still have
> to backup the storage pool) data is moved out of the storage pool.
> I understand that the COPYSTGPOOL drives count against MAXNUMMP
> (which is counter-intuitive to me), so I haven't had the nerve to
> try this.
Oh, it works pretty well, with a few glaring exceptions.
+ TDP applications tend to fail if any of the streams gets
interrupted. I understand why this happens, but it's bloody
inconvenient.
Second ( and this is, indeed, virtual-volume specific )
+ You can never ever ever re-open a virtual volume. Even on its'
first (and only) RW mount, the first process or session to write to
it is also the last. This means that, if you do too much
simultaneous write work, you end up with bajillions of tiny volumes.
For that reason, _I_ haven't had the nerve to keep trying this. :)
If you're doing local volumes, that's not going to be as much of a
problem, so you are simply constrained by your mount points. Not
perfectly convenient, but not a big deal either.
- Allen S. Rout
|
