I agree with Troy about using incr rather than sel, and using a
retention of 30-60 days to eliminate the need for the weekly backups.

As far as daily\monthly\yearly schedule control, we have something
somewhat similar here, and I decided the least complex way for me to
handle it was to control everything within a single backup script that
runs every day, with the run logic built in to it.  Your script logic
would go through a series of checks (assuming your monthly/yearly
backups would be done the first Saturday of every month/year -
eliminates pesky 28/29/30/31 days in a month issues):

1. If today is not Saturday, goto the daily backup
2. If the day is > 7, goto the daily backup 
3. If the month is no Jan, goto the monthly backup
4. goto the yearly backup

Each section would run an incremental using -optfile=xxxxx to point to
the correct nodename.  

For what it's worth, here is what my script looks like (we only do
daily/monthly)  Note that I also send info to a common runlog file so I
can easily see which schedule was run when:

@ECHO OFF

:Setup
::+===================================================================+
::| Initialize returncode, parse the current date, point to tsm dir   |
::+===================================================================+
set runhistory=runhistory.log
set standard_optfile=dsm.opt
set monthly_optfile=monthly.opt
set dayofweek=%date:~0,3%
set month=%date:~4,2%
set day=%date:~7,2%
set year=%date:~10,4%
set dailylog=dsmsched_day_%day%.log
set monthlylog=dsmsched_month_%month%.log
cd /d "c:\program files\tivoli\tsm\baclient"
set returncode=0

:Fork
::+===================================================================+
::| Execute the monthly snapshot backup if today is the first Saturday|
::|    of the month.  Otherwise, execute the normal daily backup      |
::+===================================================================+
if NOT [%dayofweek%]==[Sat] goto :Daily_Backup
if %day% GTR 7              goto :Daily_Backup
goto :Monthly_Snapshot

:Daily_Backup
::+===================================================================+
::| execute an incremental backup using the default dsm.opt file      |
::+===================================================================+
echo %date% %time% [Daily] Incremental backup for %computername%
started, using %standard_optfile%, dayofweek=%dayofweek% day=%day%
month=%month% year=%year% >> %runhistory%
dsmc incremental -optfile=%standard_optfile% > %dailylog%
set returncode=%ERRORLEVEL%
echo %date% %time%         Ended, returncode of %returncode% >>
%runhistory%
goto :Finis

:Monthly_Snapshot
::+===================================================================+
::| execute an incremental backup using the opt file for monthly snaps|
::+===================================================================+
echo %date% %time% [Monthly-Snapshot] Incremental backup for
%computername% started, using %standard_optfile%, dayofweek=%dayofweek%
day=%day% month=%month% year=%year% >> %runhistory%
dsmc incremental -nojournal -optfile=%monthly_optfile% > %monthlylog%
set returncode=%ERRORLEVEL%
echo %date% %time%                    Ended, returncode of %returncode%
>> %runhistory%
goto :Finis

:Finis
::+===================================================================+
::| Exit the script with the return code from the backup command      |
::| Note that we convert a returncode of 4 to zero since it only      |
::|    indicates that some files were missed, which is normal         |
::+===================================================================+
If [%returncode%]==[4]  set returncode=0
exit %returncode%


Hope this helps,
Steve Schaub
Systems Engineer, WNI
BlueCross BlueShield of Tennessee
423-535-6574 (desk)
423-785-7347 (cell)
***public***


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Troy Frank
Sent: Tuesday, September 12, 2006 6:06 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Weekly, Monthly, Yearly Selectives

This sounds like a classic request from management that doesn't
understand TSM works differently from typical backup software, and
they're trying to shoehorn it into behaving as they're used to.  If you
make your normal retention policy 30 versions or more, you can at least
get rid of the weekly/monthly full backups.  In our case, we do 60
versions held for 60 days.  So if/when we do longer term archives, it
would have to be at most bi-monthly.

Also, as others have mentioned before, there's no need to make these
monthly/yearly backups a selective(full).  You can just make a 12
version & 5 version management policy for the monthly & yearly backups,
respectively.  All the backups can be incremental this way, and you save
bookoo tapes & DB entries (not to mention faster backups).


>>> bscott AT EDS DOT COM 9/12/2006 4:12 PM >>>
Fellow TSM'rs,

I have been tasked to provide a backup schedule to provide weekly,
monthly, and yearly full backups for a 5 year duration. The weekly would
be retained for a month, monthly for a year, and yearly for 5 years.
I've created separate policies, nodenames, etc. to keep the policy
retentions separate. The problem I have is the actual TSM client
schedule on the server.

How do I keep the weekly selective backup from running at the end of the
month when the monthly selective is supposed to kickoff? Same thing for
the monthly at the end of the year when the yearly selective will
kickoff?

I'm running TSM server 5.3.3.0 and BA 5.3.4 and I see the Enhanced
Schedule capability to provide DAYOFWEEK and WEEKOFMONTH to which I can
set Saturday as DAYOFWEEK and First,Second,Third as WEEKOFMONTH but some
months have 4 weeks while others have 5. Also, I can't set the weekly to
be every Saturday BUT the last Saturday of the month and the montly to
be every last Saturday BUT the last Saturday of the year.

Any suggestions?

Regards,
Brian

Brian Scott
EDS
Global Client Engineering-GM
MS 3234
4594 W Nancy Dr.
Kankakee, IL 60901

( Phone:+1-815-939-2684)
+ mailto:bscott AT eds DOT com

Confidentiality Notice follows:

The information in this message (and the documents attached to it, if
any) is confidential and may be legally privileged. It is intended
solely for the addressee. Access to this message by anyone else is
unauthorized. If you are not the intended recipient, any disclosure,
copying, distribution or any action taken, or omitted to be taken in
reliance on it is prohibited and may be unlawful. If you have received
this message in error, please delete all electronic copies of this
message (and the documents attached to it, if any), destroy any hard
copies you may have created and notify me immediately by replying to
this email. Thank you.
Please see the following link for the BlueCross BlueShield of Tennessee E-mail
disclaimer:  http://www.bcbst.com/email_disclaimer.shtm