The top problems we are trying to solve are tape contention and utilization.  
Contention is a little troublesome from time to time. Utilization is why we did 
some testing to the extreme of 10GB volumes.

There are some very interesting points:
>> I think your volume size should be something fitting the data type going 
>> into the storage pool. Putting 100GB exchange db files on 10gb volumes or 
>> 1kb files on 100GB volumes doesn't seem efficient.<<

Object size is a little hard to define.  We have big DBs to millions of tiny 
files.

>> Some considerations: 
- This varies with the different VTL vendor's, but some had a maximum number of 
Virtual Tapes that was allowed in the system, which would argue for larger 
volumes.  - On the other hand, smaller volumes reduce the amount of reclamation 
you have to do (depending on your data) 
- If you ever want to export to physical tapes, you might want to just use the 
same size that you are emulating.  I.E. 400GB for LTO3>>

I had not considered the number of slots in the emulated library.
There is no chance of the VTL moving data to physical tape, our libraries are 
not supported.

>>If you try to provide virtual sequential access mount points for each client 
>>session you  may need during client processing, you will likely need much 
>>more system resources to complete nightly backups.<<

We are currently using the VTL's, so the overall design of the storage pools 
and what goes where and when it goes there is running smoothly.  We go to disk 
first except for the large objects.


>>Another thing to think about is, have you sized the virtual library to have 
>>enough capacity for all your primary storage pool needs, or will the primary 
>>pool have to migrate to real tape?<<

We have already seen the spanning tape problem with backup storage pool and 
have a procedure to handle that.  That is annoying.
The VTLs are large enough to hold the primary copy, but they are approaching 
their maximum capacity.


>> We make use of "expandable" virtual volumes with an initial size of 5G and a 
>> max size of 60G and it works well in my opinion.<<

We tried expandable or capacity on demand, but found that we generally fill the 
tapes so all we gained was an ambiguous scratch tape count.
We do have compression on; we average nearly 2:1.



The leaning here seems to be in the 50GB range.

Thank you for the responses so far.

Andy Huebner



This e-mail (including any attachments) is confidential and may be legally 
privileged. If you are not an intended recipient or an authorized 
representative of an intended recipient, you are prohibited from using, copying 
or distributing the information in this e-mail or its attachments. If you have 
received this e-mail in error, please notify the sender immediately by return 
e-mail and delete all copies of this message and any attachments.
Thank you.