Networker

Re: [Networker] Dilemma with cloning?

2004-05-26 19:38:08
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 19:39:43 -0400
Okay, I see when I go into Notifications under nwadmin, with the details
turned on, and I press create, it puts a default value in the Action
field, the Name is blank and all the events and priorities are checked.

1. How do you associate a specific group with the action? I mean, if I
list the pathname of the script in the Action field, what's gonna keep
it from running the script after every group completes? I only want it
to run the script after a certain group finishes?

2. Which events would I want: 'Savegroup' and 'Write completion' both or
just Savegroup?

3. What about priority?

4. I suppose the script has to live on the primary server and not the
storage node, correct?

I guess it doesn't matter since all the script will have to do is just
figure out which savesets from the pool have not been successfully
cloned and then run the nsrclone command against them, and that can be
run from there, too, but I normally don't run the nsrclone command on
the server. Also, I like using Perl but we don't run Perl on the primary
server (sigh) so will have to use shell script. That will make it
tougher.

Thanks.

George

Itzik Meirson wrote:
>
> George,
> You may automate the cloning and still use the manual cloning procedure.
> The way to implement this is to create a "savegroup completion"
> notification.
> The action of this notification will be a script that will handle the
> logistics for your cloning needs and invoke automatically your manual
> cloning scripts.
> The additional benefit of this approach is that your group completes and
> then the cloning starts.
> Otherwise, with automatic cloning on the group, your group backup is
> complete only at the end of the cloning.
> I hope this may provide you and alternative way to auto-magically do
> manual cloning.
> Itzik
>
> -----Original Message-----
> From: Legato NetWorker discussion [mailto:NETWORKER AT LISTMAIL.TEMPLE DOT 
> EDU]
> On Behalf Of George Sinclair
> Sent: Wednesday, May 26, 2004 23:55
> To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
> Subject: Re: [Networker] Dilemma with cloning?
>
> 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.
> =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
>
> **************************************************************************************************
> The contents of this email and any attachments are confidential.
> It is intended for the named recipient(s) only.
> If you have received this email in error please notify the system manager or  
> the
> sender immediately and do not disclose the contents to any one or make copies.
>
> MBI - System Team
> **************************************************************************************************
>
> --
> 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>