Thanks, Darren. Those are some good ideas. I think cloning the clone
will be what I'll go with. Either way, the data is being validated since
the original has to be read to be cloned anyway. BTW our SDLT and LTO
drives are not in the same libraries, but both libraries are managed by
storage node server. Just thought reading and writing would be faster in
done in same library?
George
Darren Dunham wrote:
>
> > First, as previously suggested, I've set up two clone pools: one for LTO
> > tapes and one for SDLT tapes with each specifying its respective media
> > type under the preferred media type field. My plan is to clone SDLT
> > tapes to SDLTs and LTO to LTO's which should greatly expedite cloning
> > speed by forcing the cloning to not cross media types and hence to stay
> > within the same library (faster speed).
>
> Assuming the drives are all attached to the same machine, I see no
> reason why "stay within the same library" would have anything to do with
> speed. (Of course keeping the media that same should keep things fast
> because speeds should be roughly matched, but that's a different issue).
>
> > And I can do this simultaneously
> > with nary a care, but not sure how best to expedite the process of
> > creating a second clone copy??? I don't mind if both cloned savesets are
> > on the same type of media, I just want to keep them on separate physical
> > clone volumes.
>
> You could clone the clone, rather than the master copy. That would
> guarantee that they were on separate media.
>
> > Now, if after launching the above command, and while it's still running,
> > I then launch it again, and I have a different clone volume (vol_c2)
> > available, then I'm thinking NetWorker will insist on wanting to load a
> > new clone volume, in this case vol_c2. Furthermore, since it can't clone
> > the data until the other job finishes, I'm thinking it will just sit
> > there patiently waiting, and then when the other job completes, it will
> > clone the same savesets to this other tape.
>
> Hmm. Hopefully.
>
> > Assuming this seems logical, anybody know of a way that I can best set
> > this script up? Not sure how it will know which volume to mark read-only
> > and which appendable? Seems like some careful choreography will have to
> > take place. Is there a way the script can determine all this?
>
> I think cloning the clones might be easier.
>
> Normally you'd want to clone an ssid, but that is no longer unique now
> that you've created clones. Instead, you'd use 'mminfo' to get a list
> of all the target SSIDs, but with the cloneid used on the clone tapes.
> Then feed that to nsrclone.
>
> Or, you could run all the clones once, collect a list of the cloned
> media, then run nsrclone again, giving the newly cloned volumes as the
> targets.
>
> --
> Darren Dunham ddunham AT taos DOT
> com
> Senior Technical Consultant TAOS http://www.taos.com/
> Got some Dr Pepper? San Francisco, CA bay area
> < This line left intentionally blank to confuse you. >
>
> --
> Note: To sign off this list, send a "signoff networker" command via email
> to listserv AT listmail.temple DOT edu or visit the list's Web site at
> http://listmail.temple.edu/archives/networker.html where you can
> also view and post messages to the list.
> =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
