Kinda what I figured. Thanks for all the responses.
On Thu, Oct 4, 2012 at 8:34 PM, Prather, Wanda <wanda.prat...@icfi.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@VM.MARIST.EDU] On Behalf Of > Chavdar Cholev > Sent: Thursday, September 27, 2012 4:18 AM > To: ADSM-L@VM.MARIST.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 <kmuel...@mcarta.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" <zfor...@vcu.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 <apasch...@frontier.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. > >>>> >> <deehr...@louisville.edu>**wrote: > >>>> >> > >>>> >> > >> > >> > >> -- > >> *Zoltan Forray* > >> TSM Software & Hardware Administrator Virginia Commonwealth > >> University UCC/Office of Technology Services zfor...@vcu.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 zfor...@vcu.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
