On Tue, Apr 22, 2008 at 1:43 AM, Gill, Geoffrey L.
<GEOFFREY.L.GILL AT saic DOT com> wrote:
> I have not tested this so am wondering out loud how communications work.
>  If 'a' server is set up to co-locate by filespace how does that affect
>  the backup if at all. All data here goes to disk pool first so I am
>  guessing nothing changes there and don't think there are any things I
>  need to consider.

IMHO one of the  things you need to consider is how long the migration
processes will take.
The more granular your collocation is (node group - node - filespace)
and the more nodes paticipating in collocation you have the more tape
mounts will be required, the longer it will take.
If you have many nodes collocating you may end up in a situation where
the migration process takes so long that it will not leave enough time
for running all the other tasks before your scheduled backup window
starts. (DEVclass parameter MOUNTR might prove to be useful in
decreasing the time required for collocated migration.)
Another consideration is tape utilization. With collocation enabled
tape utilization decreases because you will have many more tapes in
stat=FILLING for longer time. So if  you are tight on scratch media
you might need to double check your strategy before implementing it.


>
>
>  As for the restore though. If co-located by filespace and there are 4
>  filespaces, each on their own set of tapes, does opening one session and
>  clicking on all 4 filespaces to restore automatically mount the 4 tapes,
>  or is it somehow single threaded and just does one filespace at a time?
>  Has anyone tested to see if opening 4 separate sessions make any
>  difference how quickly data is restored to the system?

--
Warm regards,
Michael Green