Instead of using a SELECTIVE backup which you need to specify what to backup, just change the management class(es) used for the weekly/monthly/yearly backups to MODE=ABSOLUTE. Then you backup schedules are just INCREMENTAL using the existing DOMAIN, but actually FULL backups each time.
You also might want to persue with management about excluding things, like the System Object if a full BMR on the Windows server won't be required. You also may want to look at a separate instance for the weekly/monthly/yearly backups. Seeing as how you're backing up each object every month your TSM DB usage is gonna grow like crazy. You can implement it as 3 instances on the same server. That way even if it's SCSI attached tape, you can still do library sharing. You should also look at what your disaster recovery requirements are....having this ever growing weekly/monthly/yearly backup data in the TSM database along with the daily backups will make your recovery all that much longer. Usually for D/R you will be restoring to the latest possible time and having the weekly/monthly/yearly data is not immediately required. I'm going through a split of a TSM database that is now 350GB and growing 5% or more per month due to FULL monthly backups. I figure that the daily data in the DB is only about 1/4th or less of the total and right now my DBBackup runs 6+ hours. It would be easier to just setup another instance to start with using a different TCPPORT than to realize that you need to split it out later. I'm not sure what the licensing requirements are if you will be running multiple instances on the SAME box. Bill Boyer -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Scott, Brian Sent: Friday, September 15, 2006 9:39 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: Weekly, Monthly, Yearly Selectives Thanks to all for your suggestions. Because the new GM data retention policy calls for true full backups I've elected to use Selective backups to be scheduled in a weekly, monthly, and yearly fashion. To make matters worse this is for a cluster server so I created separate client scheduler, acceptor, and remote client services for the weekly, monthly, and yearly nodes of the cluster so that I can run these jobs separately and be able to access via the web browser for any restores. It looks ugly from a services and Cluster Admin perspective but it works and allows backups to run even during a failover situation. Also, I setup administrative tasks on the TSM server that will remove the nodes from the weekly backup schedule when the monthly backup occurs in place of the last weekly backup of the month. Then another set of admin tasks that reassociates the nodes after the backup runs. Same tasks are created for the weekly and monthly schedules when the yearly backup kicks off. 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] -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Troy Frank Sent: Thursday, September 14, 2006 8:31 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: Weekly, Monthly, Yearly Selectives A couple people on here had mentioned a good idea that was an alternative to running occasional archives (which are always full backups). Basically you define the client as more than one node (ie. node/node-monthly/node-yearly). You then bind these 3 nodes to different policies, and 3 different schedules. The "node" gets assigned to whatever your default retention period is (I'll say 30 versions in this case). Node-monthly gets ~13 versions, but only gets run once per month. Node-yearly gets ~ 7 versions (for a 7yr retention), and only gets run once per year. This way, your "archives" can use the same incl/excl lists as your backups, and they take less time, as they don't have to do a full after the 1st run. I would guess that others doing this have probably setup separate online & copypools for this data, just to keep it separate. One thing to watch out for with this method (differing from archives), is that by default you're back to getting 2 copies of the data....one in an onlinepool, and one in a copypool, whereas archives were only one copy. In general it's better to get 2 copies, but it will take up a lot more space in your library without preventative measures. If the 2nd copy of the data isn't important to you, you could probably forgo creating the copypool for this long-term data, and just take the online copies out of the library after each run. That would be more labor intensive for reclamation though, as you'd have to manually retrieve the tapes. >>> [EMAIL PROTECTED] 9/13/2006 11:25 PM >>> Can you explain what you mean by: "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)." As I have a similar issue. Thanks Paul Dudley > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf > Of Troy Frank > Sent: Wednesday, 13 September 2006 8:06 AM > 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. ANL DISCLAIMER This e-mail and any file attached is confidential, and intended solely to the named addressees. Any unauthorised dissemination or use is strictly prohibited. If you received this e-mail in error, please immediately notify the sender by return e-mail from your system. Please do not copy, use or make reference to it for any purpose, or disclose its contents to any person. 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.