A coupla comments... Have you checked the performance of monthly backupsets using v5??? (There are supposed to be some performance improvements in there, somewhere.)
You mention that monthly archive is "driven by the server..., so less fiddling at the client" -- how is that so? Aren't you just going to script the thing to choose the "monthly" or "yearly" -archmc?!? Also, to relieve the TSM-db consumption, have you considered either of (a) export the node (then later reincarnate the node) or (b) use a separate TSM server, and start a new db once each year? Using export node, you could be using "incremental" for the monthly/yearly -- as a "poor man's" archive of the yearly data that requires indefinite storage; Re-starting the TSM-db once every 2-5 years, to "reclaim" db space used by the annual snapshot is another alternative. Don France Technical Architect -- Tivoli Certified Consultant Tivoli Storage Manager, WinNT/2K, AIX/Unix, OS/390 San Jose, Ca (408) 257-3037 mailto:[EMAIL PROTECTED] Professional Association of Contract Employees (P.A.C.E. -- www.pacepros.com) -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Steve Harris Sent: Monday, July 01, 2002 4:39 PM To: [EMAIL PROTECTED] Subject: Re: Monthly shapshots/ Configuration management. Bill and Paul thanks for the input. The full requirement is for a full monthly backup kept 13 months and a yearly snapshot that is to be kept indefinitely. I did an analysis of 4 options using my current production servers and data volumes Monthly archive, Monthly incremental to "monthly" node Tape backupset Backupset to sequential disk files of 1 GB size which are then migrated using HSM One key problem with backupsets is the time that they take, and you're not supposed to perform any backups or expiry whilst they are being created. Given the tape usage profile on my system that means new tape drives, and costs slots in the 3494. The backupset with migration option was surprisingly even more expensive - again bigger drive requirements in order to migrate some of the backupset data files whilst the backupset is still being created . The problem with the monthly incremental is that the yearly snapshot has to be taken by a different method. Although this option did cost out cheaper, it wasn't by much. The Monthly archive costed out to be second least expensive, and the same method can be used for monthly and yearly snapshots. Its also driven from the server side and so requires less fiddling on each client. Using the KISS principle, this is the winner. The big downside is, of course, the database size increase. I can cope with the archive network load provided I split the work over the 8 days of 4 weekends. So, any input on configuration management? Steve. >>> [EMAIL PROTECTED] 29/06/2002 0:08:35 >>> Why not use backupsets? I know, you need 1 tape per server for each backupset as opposed to putting all the new monthly backup data in its own pool and filling the tapes. We thought about a couple other ways around this...virtual volumes to another server and having a FILE device class for the backupsets and then archiving the backupset files to TSM tape. For the virtual volumes, you need another TSM server license and full support for backupsets as virtual volumes is not there. The RECONCILE VOLUMES command does not recognize a backupset as a valid volume type and deletes the virtual volume, but not the related backupset entries. It works, but you have to remember to NOT run the command. For the FILE devclass, you need enough disk space to hold a backupset. Plus to restore from the backupset, you would need to retrieve the archive that contains that backupsets' files first. Just some $.02 worth... Bill Boyer DSS, Inc. >>> [EMAIL PROTECTED] 29/06/2002 11:59:36 >>> You said backup, did you mean a full incremental once a month? If so, the easiest way to do that is create a second node and second stanza in your dsm.sys for the server with a different policy domain/management class and use the -se option with a private dsm.opt for your include/exclude list. Mark the copygroup with mode=absolute. Use a separate storage pool if you would like to send just those offsite. Paul D. Seay, Jr. Technical Specialist Naptheon, INC 757-688-8180 ********************************************************************** This e-mail, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s). This confidentiality is not waived or lost if you receive it and you are not the intended recipient(s), or if it is transmitted/ received in error. Any unauthorised use, alteration, disclosure, distribution or review of this e-mail is prohibited. It may be subject to a statutory duty of confidentiality if it relates to health service matters. If you are not the intended recipient(s), or if you have received this e-mail in error, you are asked to immediately notify the sender by telephone or by return e-mail. You should also delete this e-mail message and destroy any hard copies produced. **********************************************************************
