Hi, thanks for your posting!
This is really dangerous, I also didn't think of rebinding... I think I'm going to use different nodes, not very beautiful but I guess this is the method.... regards, Volker Am Freitag, den 19.05.2006, 13:54 +0200 schrieb Salak Juraj: > Hi! > > I suspect this will not work the way you like! > > Running C:\Programme\Tivoli\TSM\TDPExchange\start_full_yearly_backup.cmd > will, up to my knowledge, rebind ALL existing TDP COPY backups to the > management class according to dsm.yearly.opt. Correct me if I am wrong. > This is not a problem so far. > > But.. Running regular monthly backup afterwards, using regular dsm.opt, > will - again - rebind ALL existing TDP COPY backups > according to dsm.opt, thus effectively shortening the life of your yearly > backups > to whatewer you defined in dsm.opt, probably one year only. > > This is why I suggested to keep all monthly backups for as long as you want > to keep yearly backups, > thus effectively replacing yearly backups by long-living monthly backups. > (you will NOT need separate yoarly backups) > Advantage: you will be able to restore e.g. 1.st april backup few years back. > Disadvantage: more space on TSM tapes, thus the suggestion of cheking old > tapes out. > > best > Juraj Salak > > > > > -----Ursprüngliche Nachricht----- > > Von: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Im > > Auftrag von Volker Maibaum > > Gesendet: Freitag, 19. Mai 2006 11:57 > > An: [email protected] > > Betreff: Re: AW: TDP for Exchange - Management Class > > > > Hi, > > > > thanks to all for the very helpful feedback! > > > > I didn't think of using the "copy backup" for monthly and > > yearly backups. That will make it a lot easier.... > > > > I guess that I will use the monthly policy for copy backups > > INCLUDE "*\...\copy" MONTHLY > > > > And use a seperate dsm.opt file (dsm.yearly.opt) to bind the > > yearly copy backups to the proper management class. > > C:\Programme\Tivoli\TSM\TDPExchange\start_full_yearly_backup.cmd > > pointing to dsm.yearly.opt > > > > regards, > > > > Volker > > > > > > > > > Am Freitag, den 19.05.2006, 11:34 +0200 schrieb Salak Juraj: > > > Hi Del! > > > > > > I might be wrong because I do not use TDP 4 Mails by > > myself, I am only > > > RTFM, but I´d think about simplified "solution 2 by Del": > > > > > > Background: > > > I think the only reason for having different requirements > > for monthly > > > an yearly backups is TSM storage space, if this were not a > > problem keeping monthly backups for as long as yearly backups > > should be kept would be preferrable. > > > > > > a) create only 1 NODENAME > > > b) define > > > INCLUDE "*\...\full" EXCH_STANDARD and maybe > > > INCLUDE "*\...\incr" EXCH_STANDARD and maybe > > > INCLUDE "*\...\diff" EXCH_STANDARD > > > appropriately to your regular (daily) backup requirements > > > > > > c) define > > > INCLUDE "*\...\copy" EXCH_MONTHLY_AND_YEARLY > > appropriate to maximal > > > combined requirements of your monthly AND yearly requirements AND > > > have EXCH_MONTHLY point to separate TSM storage pool (EXCH_VERYOLD) > > > > > > d) on regular basis (maybe yearly) check out all full tapes > > from EXCH_VERYOLD storage pool from library. > > > Disadvantage: reclamation of backup storage pool issues because of > > > offsite tapes in primary storage pool, but this can be > > solved as well. > > > > > > You will end with a bit less automated restore (only) for very old > > > data but with very clear and simple concept for everyda/everymonth > > > backup operations and with more granularity (monthly) even > > for data older than a year. > > > > > > I am interested in your thoughts and doubts about this > > configuration! > > > > > > regards > > > Juraj > > > > > > > > > > > > > > > > -----Ursprüngliche Nachricht----- > > > > Von: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Im > > > > Auftrag von Del Hoobler > > > > Gesendet: Freitag, 12. Mai 2006 15:14 > > > > An: [email protected] > > > > Betreff: Re: TDP for Exchange - Management Class > > > > > > > > Hi Volker, > > > > > > > > Are you using separate NODENAMEs for each of the > > different DSM.OPT > > > > files? If not, your solution won't do what you think. > > > > > > > > Data Protection for Exchange stores objects in the backup > > pool, not > > > > the archive pool. That means, each full backup gets the same TSM > > > > Server name (similar to backing the same file name up with the BA > > > > Client.) It follows normal TSM Server policy rules. > > > > That means, if you are performing FULL backups using the same > > > > NODENAME, each time you back up with a different > > management class, > > > > all previous backups will get rebound to that new management > > > > class... just like BA Client file backups. > > > > Remember, this is standard behavior for BACKUP. You are trying to > > > > get ARCHIVE type function, which won't work. > > > > > > > > Good news... there is a way to do exactly what you want... > > > > ... I have two ways to do it. > > > > > > > > Solution 1: > > > > Create a separate NODENAME for your 3 types of backups. > > > > For example: EXCHSRV1, EXCHSRV1_MONTHLY, EXCHSRV1_YEARLY > > > > Have a separate DSM.OPT for each NODENAME, with the proper > > > > management class bindings. Set up your three schedules for > > > > your three separate nodenames. > > > > > > > > Solution 2: > > > > Create 2 separate NODENAMEs. Use one for the STANDARD and > > > > MONTHLY backups (perform COPY type backups for your MONTHLY > > > > backups). > > > > Use the other nodename for the YEARLY backups. > > > > For example: EXCHSRV1, EXCHSRV1_YEARLY > > > > Have one DSM.OPT for your STANDARD and MONTHLY backups and > > > > a different DSM.OPT for your YEARLY backups. > > > > In the DSM.OPT file for your STANDARD and MONTHLY backups, > > > > set up different policy bindings for FULL backups vs. COPY > > > > backups (since FULL and COPY get named differently on the > > > > TSM Server, they will also get their own policy.) > > > > > > > > Example DSM.OPT INCLUDE statements are like this: > > > > *---* The following example binds all FULL objects > > > > *---* to management class EXCH_STANDARD: > > > > INCLUDE "*\...\full" EXCH_STANDARD > > > > > > > > *---* The following example binds all COPY objects > > > > *---* to management class EXCH_MONTHLY: > > > > INCLUDE "*\...\copy" EXCH_MONTHLY > > > > > > > > > > > > As far as your original question... you can check the management > > > > class bindings by bringing up the Data Protection for Exchange > > > > GUI... go to the restore tab, click on the storage group > > you want to > > > > look at. It will show the management class bindings. > > (Make sure to > > > > view active and inactive, to see the previous backup bindings as > > > > well.) You can also use the SHOW VERSION TSM Server command: > > > > SHOW VERSION EXCHSRV1 * > > > > SHOW VERSION EXCHSRV1_MONTHLY * > > > > SHOW VERSION EXCHSRV1_YEARLY * > > > > This will show you the management class bindings. > > > > > > > > I hope this helps. Let me know if any of this isn't clear. > > > > > > > > Thanks, > > > > > > > > Del > > > > > > > > ---------------------------------------------------- > > > > > > > > > > > > "ADSM: Dist Stor Manager" <[email protected]> wrote on > > 05/12/2006 > > > > 03:03:17 AM: > > > > > > > > > Hi, > > > > > > > > > > I want to do daily, monthly and yearly backups of our > > > > Exchange Server. > > > > > Therefore I defined three management classes: > > > > > 1) standard (for daily backups - 14 days retention) > > > > > 2) monthly (365 days retentions, backup once a month) > > > > > 3) yearly (5 years retention, backup once a year) > > > > > > > > > > I also defined three schedules on the server side, > > starting three > > > > > different command files on our exchange server which are using > > > > > different dsm.opt files. > > > > > > > > > > I now want to check if the backups are bound to the correct > > > > management > > > > > class. The following command shows me all backups but not the > > > > > management classes. > > > > > tdpexcc query tsm * /all > > > > > > > > > > Is there a way to view the management class to each backup? > > > > > > > > > > regards, > > > > > > > > > > Volker > > > > > >
