ADSM-L

Re: [ADSM-L] Stopping backups from running during certain hours

2012-09-26 15:17:17
Subject: Re: [ADSM-L] Stopping backups from running during certain hours
From: Skylar Thompson <skylar2 AT U.WASHINGTON DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 26 Sep 2012 11:25:17 -0700
Can you lock the node before you cancel the sessions, and then unlock it
when the backup window starts in the evening?

-- Skylar Thompson (skylar2 AT u.washington DOT edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of Medicine

On 09/26/12 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:

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