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:
> You would want to grep for Node in the q sess output so that you don't
> cancel Admin sessions.
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of
> Alex Paschal
> Sent: Wednesday, September 26, 2012 12:41 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] Stopping backups from running during certain hours
>
> As far as killing those sessions goes, something like this might do the
> job. Just put it in a script, cron it for 7am.
> dsmadmc -id=id -pa=pa cancel session all
> Heheh - talk about a big stick.
>
> If you need it to cancel only certain nodes' sessions, you could try
> something like this. Put the node names in a text file, and ...
> dsmadmc -id=id -pa=pa -dataonly=yes -tab query session | grep -wf
> nodes.txt | awk -F\asdf '{print $1}' | tr -d , | awk '{print "cancel
> session ", $1}' | dsmadmc -id=id -pa=pa
> Note: The "asdf" is actually a typed tab character.
>
> It will definitely need polishing before being ready for production,
> error checking, logging, notifying, stuff like that, but that's the
> essense of the script.
>
> On 9/26/2012 7:32 AM, Zoltan Forray wrote:
> > *"Could you monitor the TSM sessions and ensure that if one is still
> going
> > it it put on hold from 7:00 am to 11:00 pm during the work week."*
> >
> > Yes, the above sentence is what I have been tasked with.
> >
> > Some back-story........
> >
> > We have some non-local nodes that often backup terabytes of data, thereby
> > sometimes running for >16-hours and often many days. Unfortunately, due
> to
> > their physical location and other networking issues, their traffic comes
> > across a 10/100 connection. We recently had some "networking slowdowns"
> and
> > someone noticed a large amount of traffic across this switch (never mind
> > the problem was actually diagnosed to be a firewall problem....) .....
> > even-though this has been happening for a long, long time. So, TSM has
> > become the whipping-boy for network related slowdowns (<2% of the TSM
> nodes
> > are not local/on private GB connection)
> >
> > I am not aware of a server-side function/process that can kill a running
> > backup (never-mind that a physical body will have to check active backup
> > sessions and figure out which might cause problems) and stop the node
> from
> > reconnecting almost immediately (unless something has changed, you can't
> > update a node to lock it while it is active).
> >
> > Thoughts.....suggestions.......ideas......rants................
> > --
> > *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
|
