TSM Server Script Maintenance

ad283m

ADSM.ORG Member
Joined
Sep 22, 2010
Messages
156
Reaction score
1
Points
0
PREDATAR Control23

Hi all!!!

I have done this script to automate the server operations, right now the operative is this:

  • 5 PM to 8 AM: Backup the clients
  • 8 AM to 10 AM: Backup the server database
  • 12 PM to 1 PM: Expiration.
The move data is done manually by the operators

We backup up directly to tape, and on the parameter next storage pool, there is nothing defined.

Regardless to say the move data by hand is simple awful :mad:, and I'd love to avoid doing it manually, so the script is this:

/* Backup DB*/
backup db t=full devclass=LTOCLASS3 wait=yes

/* Expiration*/
exp in wait=yes duration=120
/* Reclamation*/
recla stg SP_1_LTO3 th=51 du=55 wait=yes
recla stg SP_2_LTO3 th=51 du=115 wait=yes
recla stg SP_3_LTO3 th=51 du=55 wait=yes
/* Migration*/
mig stg SP_1_LTO3 th=0 du=25 wait=yes
mig stg SP_2_LTO3 th=0 du=55 wait=yes
mig stg SP_3_LTO3 th=0 du=25 wait=yes

As far as I know, or understand :S, the migration will do the move data for the tapes automatically, but what should I put as the next pool, the same pool? Because I got confused by the manual since it's usually refered to do the migration from disk to tape, and that's not the case here.

I don't want to mix the data and much less to lose the inactive versions that haven't expired.

Please any input would be greatly appreciated.
 
PREDATAR Control23

If your data is already on tape I wouldn't expect you need to migrate it to anywhere else? Migration/moves is for moving data from one storage pool to another. You don't need to do it unless you want/need to move it.
 
PREDATAR Control23

Hi,

Well actually we need to move it because sometimes there are like 8 tapes and each with just 5 or 10 %, we dont use collocation.

We use the move data to put 2 tapes on 10% to just 1 with 20%, on the same storage pool.

Also, we run monthly backups with a different storage pool, management class and we must have sufficient Scratch, otherwise the backups will fail.

Sooo, I'll guess the migration it's out of question???, any suggestions because moving data manually it's plain awful.

The rest of the script how does it looks???
 
PREDATAR Control23

So what you are really asking, is how to free up these tapes that have say 10% of data on them?

Are the tapes full or filling status, and are they offsite or onsite tapes? This affects the way their %pct_reclaim is calculated. I'm guessing they're still filling? You could try to reduce the number of filling tapes by checking that collocation is not enabled or set to "group", and avoiding writing to more than 1 tape in stgpool at a time. Otherwise you could write a script (pick your language) that selects the tapes that need to be moved, and then moves them.
 
PREDATAR Control23

The tapes some of them are Full, others Filling, so Reclamation works for me, up to a point.

To free the data of them we usually do a move data. So What I am asking is if there is a way to do this automatically??

The tapes are onsite and regarding collocation is set to No. Basically the problem here is that we have 4 drives and 3 stg pools for the daily backups (SQL, Exchange and data) and sometimes the backups are looonng for certain clients, and we usually tend to write more than 1 tape for the same storage pool at the same time.

I wanted to avoid doing a Script to do the move data (not very well versed on scripting) and I was wondering if I could use tools of TSM without doing any script.

Sorry if I was confusing posting the question.
 
PREDATAR Control23

If the volumes are filling and onsite, and hence have a low %pct_reclaim I don't know of any "easy" way to do this without a script.
 
PREDATAR Control23

Precisely,

I have found Scripts but they are for Unix, AIX, but I'm windows, so no clue on how to make the script work.

So far I have been able to put the command on a table, but still I need to execute it.

Or I'm able to recognize the volumes, but to execute the command, no luck with that.
 
PREDATAR Control23

you can try in this way

select 'move data '||volume_name||' wait=yes' from volumes where pct_utilization>60 and status='Filling' > file_path/move_data.cmd
macro move_data.cmd

you can schedule them daily.

you can edit the select cmd as per ur requirement the only thing you need to take care is to delete the heading of the o/p i.e. first 2 lines at OS level
 
PREDATAR Control23

Hi, thanks for the answer,

Yes, I did it like that, and it works!!!. However the macros cannot be scheduled (According to the manual)

I'm now trying to see how to direct the output but the hardest part is done (A combination of a script and a macro)

Thanks all!!!

I'll post the final once I get it done.
 
PREDATAR Control23

define schedule schedule_name t=admin cmd="macro file_path" startd= ................................................

The above works...check out
 
PREDATAR Control23

Hi Sandeep,

Did U really try to schedule a macro command by an administrative schedule ?

The official documentation states it's not possible : "1. You cannot schedule the MACRO command or the QUERY ACTLOG command." (see H DEF SCHED).

I've tried it anyway, but I got this message :
ANR2755E DEFINE SCHEDULE or UPDATE SCHEDULE parameter CMD='macro c:\file.mac' - not eligible for scheduling.

So, I guess it's impossible that way !

There's a way for doing that wich is defining a script from a file then schedule this script. But there's still a problem about generating the file because redirections are not available from a schedule...

Please check before posting...
 
PREDATAR Control23

Hi ad283m,

You're completely false, you need to review the basics concepts of TSM or you'll get nuts soon whith working that way. The main problem is that TSM does not multiplex backups to tapes, so you need to backup to a disk storage pools then migrate to a tape storage pool. This will avoid the need of move data by hand.

As a general rule, you should move (or copy) data by storage pools, not by volumes !

Please read this redbook (some parts of) :
http://www.redbooks.ibm.com/abstracts/sg244877.html

Regards,
Erwann
 
PREDATAR Control23

Hi erwans, I am completely false regarding what???? Be a little more specific.

I do agree that I should backup to disk and then migrate, if I did that I wouldn't have this awful headache regarding the management of my tapes, now would I?

But there is a little problem here, I don't have the space to backup first on disk, so unless I have 6 TB available on disk soon I'll have to keep backing up to tape directly, hence the move of the data.

Remember the book says one thing but another is each company infraestructure, so we must adapt.

On another thing here, you sould be a bit more polite, the coments "Did U really try to schedule a macro command by an administrative schedule ? " and "You're completely false, you need to review the basics concepts of TSM " are not exactly the best way to point out an error here.

I mean, be specific and point the mistakes without being demeaning, not even the top poster here does that (And he has responded me some posts)


Hi ad283m,

You're completely false, you need to review the basics concepts of TSM or you'll get nuts soon whith working that way. The main problem is that TSM does not multiplex backups to tapes, so you need to backup to a disk storage pools then migrate to a tape storage pool. This will avoid the need of move data by hand.

As a general rule, you should move (or copy) data by storage pools, not by volumes !

Please read this redbook (some parts of) :
http://www.redbooks.ibm.com/abstracts/sg244877.html

Regards,
Erwann
 
PREDATAR Control23

Hi ad283m,

I was not my intention to be rude or demeaning to you. You're right when you say that I should have been more specific.

I wanted say you were probably following the wrong way by looking for a solution with scripting. It's not the way TSM works, so it's generally not the best solution for general purpose.

As you can figure, sending incremental backups of data to tape is not a good way : no multiplexing, many filling tapes, low perfomances... However, SQL and Exchange full backups are good candidates to be send to tape directly.

The problem here is not a TSM problem problem but an architecture problem, and you're really aware of that. According to me, scripting is not the solution. The solution is an architecture review.

Maybe you'd better moving your tape pools to second level rape pools by migration rather than doing move data by hand as it could be automated by the migrate stg command. As you know this command works by storage pools, and has duration and wait=yes parameters to control it's execution time. I've never done that but I think it could be easier than those move data things.

If you want to automate the generating of move data commands by TSM is to :
1 - define a move_data TSM script with that select :
select 'move data '||volume_name||' wait=yes' from volumes where pct_utilization>60 and status='Filling'

The command to use could be :
DEF SCR move_data "select 'move data '||volume_name||' wait=yes' from volumes where pct_utilization>60 and status='Filling'" desc="Some description"

Note that you could replace 60 by $1 in order to easily change the threshold while running the script.

2 - write a simple windows batch file i.e :
<code>
cd "c:\Program Files\Tivoli\TSM\baclient"
dsmadmc -id=xxxx -pa=xxxx -datao=y "run move_data" > file_path/move_data.mac"
dsmadmc -id=xxxx -pa=xxxx -datao=y -itemcommit "macro file_path/move_data.mac"
</code>

3 - schedule the execution of that batch file with a CLIENT schedule with an action=command by defining (or updating) this schedule in your main TSM admin script
the schedule must be set to run now (startd=today, startt=now), one time (peru=onetime) and the client scheduler should be on prompted mode.

Regading my comment to Sandeep, I think he shouldn't wrtite things that are false as it couldn't help.

Regards,
Erwann


Hi erwans, I am completely false regarding what???? Be a little more specific.

I do agree that I should backup to disk and then migrate, if I did that I wouldn't have this awful headache regarding the management of my tapes, now would I?

But there is a little problem here, I don't have the space to backup first on disk, so unless I have 6 TB available on disk soon I'll have to keep backing up to tape directly, hence the move of the data.

Remember the book says one thing but another is each company infraestructure, so we must adapt.

On another thing here, you sould be a bit more polite, the coments "Did U really try to schedule a macro command by an administrative schedule ? " and "You're completely false, you need to review the basics concepts of TSM " are not exactly the best way to point out an error here.

I mean, be specific and point the mistakes without being demeaning, not even the top poster here does that (And he has responded me some posts)
 
PREDATAR Control23

I do believe the solution on using a secondary tape pool might do the trick (I really didn't think of that one) pretty much because unlike the move data I can control the duration.

I did it using the script but as you said it's not really the best way to go around it.

Thanks for the suggestion.
 
PREDATAR Control23

my script is :

tsm: TSM02-F2>q script maint f=d

Name Line Command
Number

------------------------------ ------ ---------------------------------------------------------------------------------------------------- ---------------
MAINT 2 backup db devc=u5nk3b type=inc w=y
MAINT 10 backup stg toc copy maxproc=1 w=y
MAINT 25 SERIAL
MAINT 30 backup db devc=u5nk3b type=full w=y
MAINT 35 backup devconfig
MAINT 40 backup volhist
MAINT 45 del volhist type=dbb todate=today-7
MAINT 50 expire inventory resource=8 dur=120 w=y
MAINT 55 audit licen
MAINT 60 PARALLEL
MAINT 65 reclaim stg file thr=20 dur=720 w=y
MAINT 70 reclaim stg prim thr=50 dur=720 w=y
MAINT 75 reclaim stg copy thr=50 dur=720 w=y
MAINT 80 SERIAL
 
Top