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
|
