Kinda what I figured.
Thanks for all the responses.
On Thu, Oct 4, 2012 at 8:34 PM, Prather, Wanda <Wanda.Prather AT icfi DOT
com>wrote:
> I think there is just not a good way to do this from the server end.
> Since these are apparently well-known clients, how about a script on the
> client end?
> perl script #1 wakes up at the witching hour and cancels the dsmc sched
> daemon, whether it's running or not.
> perl script #2 wakes up at the "toleration" hour and restarts dsmc sched.
> Then the backup will only restart if it's within the schedule window.
>
>
>
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of
> Chavdar Cholev
> Sent: Thursday, September 27, 2012 4:18 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] Stopping backups from running during certain hours
>
> Hi Zolatan,
> you can create to schedules in tsm like:
> Sch No 1
> 1) disable sess for node
> 2) can ses
> After the period of time is passed:
> 1) enable ses
> 2) prompt client to start backup ...
>
> Regards
> Chavdar
>
> On Thu, Sep 27, 2012 at 12:27 AM, Ken Mueller <kmueller AT mcarta DOT com>
> wrote:
> > To step a little bit outside of the TSM box, have you considered using
> > iptables (you¹re a Linux shop, right?) with a time rule on the TSM
> > server to block these troublesome hosts/subnets from connecting to TSM
> > during undesirable times. You can either be heavy-handed and stop any
> > matching packet after the witching hour, or let existing connections
> > survive (so you can more gracefully stop them using cancel session).
> > -Ken
> >
> >
> > On 9/26/12 4:23 PM, "Zoltan Forray" <zforray AT VCU DOT EDU> wrote:
> >
> >> That is my whole point of my question/this discussion. So far the
> >> only thing to do is what I already thought of (1-disable sessions,
> >> 2-cancel session, 3-try to lock the node in-between retries...) but
> >> that in itself is problematic since the node will "keep banging on
> >> the door" for a while trying to re-establish the failed connection
> before it gives up...
> >>
> >> Also, disabling sessions will effect every node on that TSM server,
> >> including legitimate backups that run throughout the day that don't
> >> effect network traffic since they are on their own private subnet....
> >>
> >> On Wed, Sep 26, 2012 at 4:15 PM, Alex Paschal <apaschal5 AT frontier DOT
> >> com
> >wrote:
> >>
> >>> > Out of curiosity, when you cancel the sessions manually, how do
> >>> > you stop them from restarting?
> >>> >
> >>> >
> >>> > On 9/26/2012 11:15 AM, Zoltan Forray wrote:
> >>> >
> >>>> >> All of this discussion is great but the bigger picture/issue is
> >>>> >> being missed.
> >>>> >>
> >>>> >> Yes, I would like to automate it but isn't really possible since
> >>>> >> it is subjective to which one is eligible to be canceled.
> >>>> >>
> >>>> >> If I (or an operator) figure out which to cancel and then cancel
> >>>> >> it, backup session will automatically restart and keep on going.
> >>>> >> I want to be able to stop it from restarting, as well!
> >>>> >>
> >>>> >> On Wed, Sep 26, 2012 at 1:28 PM, Ehresman,David E.
> >>>> >> <deehre01 AT louisville DOT edu>**wrote:
> >>>> >>
> >>>> >>
> >>
> >>
> >> --
> >> *Zoltan Forray*
> >> TSM Software & Hardware Administrator Virginia Commonwealth
> >> University UCC/Office of Technology Services zforray AT vcu DOT edu -
> >> 804-828-4807 Don't be a phishing victim - VCU and other reputable
> >> organizations will never use email to request that you reply with
> >> your password, social security number or confidential personal
> >> information. For more details visit
> >> http://infosecurity.vcu.edu/phishing.html
>
--
*Zoltan Forray*
TSM Software & Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zforray AT vcu DOT edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit http://infosecurity.vcu.edu/phishing.html
|
