Each node has a nodename assigned for the monthly backup <nodename>_M, and that's in it's own domain LONGTERM. The policy is VERE/VERD=NOLIM RETE/RETO=2570 and it goes to it's own disk/tape pools, separate from the daily backups. Right now there are 179 nodes registered in that domain. Not all of them are active right now, and I did manage to get them to at least run the test/dev/prod on different schedules. So they're not all trying to hit the system at the same day.
The daily backup of this system in 1.5TB and more. Lots of Oracle backups. I'm trying to get them to buy off on using compression for the *.DBF files. They do it for test/dev and I see as high as 84% client side compression. The tape is LTO-1. They have a 3584 with 4 drives and a 3583 with 4 drives, but right now (excluding the monthly tapes) they have over 150 tape volumes that don't fit in the 2 libraries. I also have them looking for an expansion frame on the used market for the 3584. Next year they have budgeted to upgrade tape to LTO-3 fibre attached. The database is 225GB and 87% full. Probably 3/4 of the monthly data is not on a copypool tape. There just isn't time and space for enough scratch tapes plus the primary pool tapes in the library. Once they are done, I have to get them out of the library to make room for more scratch tapes to allow the daily backup to continue. I did get them to change their policy do that test/dev servers will be reduced to a 90-day monthly retention. For some of these there's almost 2-years of monthly backups that will expire once I move them into that domain. That will also give me some space back in the database. For a full montly rotation the DB grows by about 5%. We are also talking about taking the monthly nodes/data to their own server instance. Right now the server has 3 instances: One is the library manager instance, then there's this production instance and there is another created that is supposed to be the monthly instance. It just hasn't been implemented. There are positive things happening. I have a list of the computers that should be backed up and any not on that list can be removed from TSM. I'm also producing a list of filespaces that haven't been backed up in 180-days. I'm not allowed to delete anything from a production monthly backup, but if I can remove these filespaces from the daily data...works for me. I've gotten a couple good suggestions and am looking into them. Thanks for the input. Bill Boyer "Some days you're the bug, some days you're the windshield" - ?? -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Allen S. Rout Sent: Friday, September 02, 2005 6:54 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: Monthly full backups with MODE=ABSOLUTE ==> On Thu, 1 Sep 2005 11:21:39 -0400, William Boyer <[EMAIL PROTECTED]> said: > I have a client with requirements for full monthly backups being > retained for 7-years. 2-years ago we set them up with monthly > schedules in a domain with the copygroups set to MODE=ABSOLUTE. Now > these backups are running forever and I think it has to do with so > many versions of the files and an INCREMENTAL schedule. The admin of > ths shop has said that the monthly backups take longer each month. > My question...would setting -INCRBYDATE help with this? These backups > MUST be a FULL. No choice on that. What are your retention parameters for those nodes? If you're not separating the monthly-full nodes from the nightly nodes, you've surely got VEREXISTS higher than 48, right? Is it NOLIMIT, with RETEXTRA set at 7 years? So, somewhere between 48 and 2500 VEREXISTS [mumble] It's an important server else they wouldn't care.. 1M files or more, right? Conservative target of 48M files for that one node, up to two -BILLION- objects for the one node. Onsite copy, offsite copy? That's what, 230GB of database size for one node? Eugh. Here's a plan: For your monthly fulls, make a new devclass ( or even a separate server??) , inaugurate a new node every month. Run your normal incrementals in a sane manner, completely separately. Then every month do: RENAME NODE monthly-thing thing-YYYY-MM REG NODE monthly-thing boogabooga Put it in a special stgpool, back that up to a special copypool. Whenever a tape gets full, check it out and stick it on the shelf. Written once, never going to be reclaimed, why keep it near-line? You only keep one primary volume and one copy volume on deck, your management feels happy, and you've kept the backups chunked sufficiently small that you can manage moving them when it comes time to shift media format. Might you answer their need by cutting a backupset monthly? Then you can store all that catalog information on shelves instead of in your DB. - Allen S. Rout
