I am not sure if you have 4 TSM Servers (instances) or 4 TSM Clients/Nodes.
- A VTL will not reduce the size of a TSM Database. - Yes, the TSM DB tracks the location of the data in all of the primary and copy pools. It has to in order to be able to use the data. - Their disk pool is their first "Primary" pool. It sounds like the VTL is a migration destination as the next Primary pool in the hierarchy. If the VTL is large enough to keep all of your active and inactive versions of objects, you would not necessarily need a next step in the Primary Pool hierarchy to tape. But, since the user wants a tape "copy" of the data, it is possible to migrate to a tape PRIMARY storage pool and/or copy to a tape COPY storage pool. TSM's INCREMENTAL backups backup objects, not the entire server or desktop. An incremental backup is an event, not an entire entity. There is nothing unified to move, or copy to anywhere. TSM does have a SELECTIVE backup option. That behaves as a FULL backup. Making frequent Selective backups will make your database grow a lot more than incremental backups will. - Our practice is to do incremental backups. We write the data to disk or VTL (it varies) then migrate to tape primary pools (for onsite copies) and copy to tape copy pools (for offsite copies.) We move the most recent copy pool tapes offsite daily. TSM takes care of expiring the data on tapes according to the retention polices defined under the Management Classes in the Copy Group definitions. So we back up the data. We have one copy, on disk for example. COPY operations move (as much data as possible in the time available) to a tape copy pool. Some data now has two copies. At a scheduled time, or when a threshold is met, data MIGRATES to the next PRIMARY storage pool (VTL in this example), no new copy of it is made, it just moves from one media pool to another. Copy operations move more data from the VTL pool to the Tape Copy Pool. Now more data has a second copy. Again, a Migration process moves data to the final Tape PRIMARY Pool. It is still just a move operation from lower capacity expensive media to less expensive higher capacity media, no new copy is made. Finally, any remaining Primary Pool data in the Tape PRIMARY Pool that has not been copied to the Tape Copy Pool...is copied. Now there are two copies of all the data that was backed up at date mm/dd/yyyy hh:mm for a particular client node. *** We do not use storage pools for Active data. They might suit your needs. They keep copies of objects that were current on the Clients as of the last backup. - If you want to do a Point-It-Time restore for a folder or entire server you can do that, TSM knows where all the data resides. It does not care if it is all on one tape, or even in the same pool. - What level of granularity - That is a wide question - you can manage by file or folder; for example, you could keep all the data in one folder for 5 days, and another folder for 15 days; or, retain files of one type for 5 days and files of other types for 30 days. I am not aware of a way to keep particular types of data in a storage pool level for any period of time other than adjusting migration policies. - What is their reason for wanting fresh backups on VTL and older backups on Tape, speed of restore from VTL, with tape for added capacity? - If your DB is growing too much, look at what you are backing up, and how long you keep it; both the length of time, and number of versions. Windows Systemstate backups involve a LOT of objects, each of them adds space to the database. (Note that the database grows by the number of objects that it tracks, not the amount of data backed up. Five thousand 1KB files take up more space in the DB than one 200 GB file.) -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Capo Sent: Friday, October 15, 2010 4:35 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM + VTL and physical tape library Hi all, I'm involved in a TSM + VTL project but, unfortunately, I'm quite new in TSM world: please apology me if I make trivial questions: My customer has currently got 4 TSM instances copying to a small disk pool and then to an IBM Tape library. They would like to introduce a VTL in the existing environment to improve overall performances and give TSM servers a little break. My questions: 1. TSM catalog is growing too much. Would VTL help them to reduce its size ? When data are copied offline (I suppose via a copy pool), does the catalog still keeps track of them? 2. Physical tape generation from Virtual media is really important in this project: customer would like to keep fresh backups on VTL and old ones on tape. With other BU applications this would be quite easy but, since TSM has got a peculiar way to manage files (versions), I am a confused: do you think that defining the tape library as a copy pool is a good idea? What level of granularity can I reach with the storage policies and copy pools? Can I simulate the lifecycle policy of other backup applications ? Can I tell migrate XX backup to tape after 1 month and remove it from the VTL and stuff like that ? 3. Any real life experience to share ? The candidates for this project are Centricstor and DXi 7500 (or the new DXi 8500). Thanks for your help Max +---------------------------------------------------------------------- |This was sent by max.c...@gmail.com via Backup Central. |Forward SPAM to ab...@backupcentral.com. +---------------------------------------------------------------------- IMPORTANT: E-mail sent through the Internet is not secure. Legg Mason therefore recommends that you do not send any confidential or sensitive information to us via electronic mail, including social security numbers, account numbers, or personal identification numbers. Delivery, and or timely delivery of Internet mail is not guaranteed. Legg Mason therefore recommends that you do not send time sensitive or action-oriented messages to us via electronic mail. This message is intended for the addressee only and may contain privileged or confidential information. Unless you are the intended recipient, you may not use, copy or disclose to anyone any information contained in this message. If you have received this message in error, please notify the author by replying to this message and then kindly delete the message. Thank you.