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:[EMAIL PROTECTED] On Behalf Of Troy Frank Sent: Tuesday, September 12, 2006 6:06 PM To: ADSM-L@VM.MARIST.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). >>> [EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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
