Networker

Re: [Networker] Dilemma with cloning?

2004-05-26 16:53:49
Subject: Re: [Networker] Dilemma with cloning?
From: George Sinclair <George.Sinclair AT NOAA DOT GOV>
To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
Date: Wed, 26 May 2004 16:55:21 -0400
Yes, of course, we can do this, and this was what I was originally
planning to do. I decided that having two separate pools would enable me
to simply specify which one I wanted depending on the media type that
the original saveset was located on, and this would take care of
everything, BUT fast forward a week. Now, I'm thinking that I don't
really want to have to manually clone stuff every day or even every
week. This is very important data and really needs to be cloned ASAP
after the original is saved. I'd really rather just have it get done
automatically because it's one less thing to worry about. For this data,
we run incrementals every night, level 5 mid-month and a full at the end
of every month. Manually doing the fulls wouldn't be too bad since that
would only be once a month, but having to clone the incrementals every
day would be a pain, but I guess I could script it and/or I could wait,
and do everything together since most of the incrementals are not that
large, but I'd really rather not get behind, so automating it just
seemed easier except for the limitation discussed. No, I don't think you
were missing anything, but I may not have been clear.

It sounds like if we want to automate it then we have three choices:

1. Have one pool and just live with the fact that it might clone from
one type to the other.
2. Same as above but write-protect the media we don't want getting used
for clones until we're ready to use it.
3. Use two clone pools, but depending on which ever is specified in the
group, simply make sure that there are enough volumes of that media type
in the given library and periodically switch the pool so the other will
get used. This will also require, though, having to write-protect the
media we don't want the originals getting written to so as to force the
cloning onto the same media type.

Maybe manually doing it would be best? I guess I could have a cron job
kick off in the morning and wouldn't take too long since incrementals
are not that big. For fulls, will take much longer so would prefer to
run at night, but I could enable automated method and just set up
everything in advance and then disable next morning if completed okay?
Would only have to set it up once a month. Hmm ...

Thanks.

George

Robert Maiello wrote:
>
> If your manually cloning couldn't you:
>
> a.) Sort the data to be cloned by media type.
> b.) Clone it to the appropriate media type/clone pool.
>
> Or am I missing something?   It would seem that, if your automatically
> cloning by group your going to be limited somewhat.   While I don't have
> mixed media we clone manually in order to get around some of these 
> limitations.
>
> Robert Maiello
> Thomson Healthcare
>
> On Wed, 26 May 2004 14:59:08 -0400, George Sinclair
> <George.Sinclair AT NOAA DOT GOV> wrote:
>
> >I have this dilemma here. I have a pool called: ARC and two clone pools:
> >'ARC SDLT Clone' and 'ARC LTO Clone'.
> >
> >I would like a clone operation to take place immediately after the arc
> >group (uses ARC pool) completes, but I would like to be able to ensure
> >that that correct media will get used to clone the data. We use two
> >media types: SDLT and LTO on two different libraries. In our case, both
> >libraries are connected to the same storagenode server, so there's
> >currently no speed loss when cloning between various devices, BUT at
> >some point in the near future this may change wherein the libraries may
> >no longer be on the same storagenode server. At that point, the network
> >will be involved when cloning from one type to the other which will slow
> >things down, so I created two clone pools, one for SDLT and one for LTO
> >with the intention of being able to specify the appropriate pool when
> >performing manual clones so that reads and writes from original to clone
> >would ALWAYS take place on the same library for speed and performance.
> >Each pool has its volume type preference specified so this solved the
> >problem when doing manual cloning, but for automatic cloning I'm at a
> >loss ...
> >
> >The arc group has the 'Clones' field set to 'Yes', but the problem is
> >that I can only put one value in the 'Clone pool' field, so which pool
> >do I specify? Clearly, I can use either, and that will work, but there
> >are two issues: 1. The other will never get used and 2. Because there's
> >no way to know which original media type will get used, there's no way
> >to guarantee that the cloning will not cross the network when the
> >libraries are separated. It would be nice if you could tell NetWorker to
> >always clone to media in the same library unless none is available and
> >then use the other library. Of course, I can play games with specifying
> >a volume type preference in the ARC pool, write-protecting the SDLT
> >media and specifying LTO in the Clone pool field or vice versa and then
> >periodically alternating, and this way I know it will clone to the same
> >media type, but here I'm hard coding it, and I'd prefer not to have to
> >do that. Or I could just have one clone pool, so then there's only one
> >value to specify, but in that case I still have no control over which
> >media type it uses to clone unless, again, I hard code the volume type
> >preference in the ARC pool, but then I lose my flexibility. I really
> >wanna have ARC pool volumes of both media types, and ARC Clone volumes
> >of both media types but would like to keep like with like and still
> >automate the cloning process when the group completes.
> >
> >Aside from having two different groups, I don't see a way to do it, and
> >two groups doesn't help me.
> >
> >Any ideas?
> >
> >Thanks,
> >
> >George
> >
> >--
> >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.
> =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

--
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.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

<Prev in Thread] Current Thread [Next in Thread>