Re: TSM + VTL and physical tape library
Capo tsm-fo...@backupcentral.com 10/15/2010 4:35 AM 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 ? No. The TSM DB keeps tracks of where things are. A VTL would not reduce its size. When data are copied offline (I suppose via a copy pool), does the catalog still keeps track of them? Yes 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? I would recommend defining the VTL as a PRIMARY storage pool replacing the disk storage pool and the physical tape as a COPY storage pool. Then backup directly to VTL and make a copy each day to the physical tape. 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. +--
Re: TSM + VTL and physical tape library
We use a disk pool to catch the data during the backup window. 300-400 simultaneous sessions. We have physical tape to create our off-site (copy pools) copy. We have VTLs to store the on-site (primary) copy of the data. It has been that way for 5 years. Various pieces have been replace. As far as making TSM act like other backup applications, I think it can be done, but I am not sure why. There are previous discussions on this. We only send certain primary pools to the copy pools, so you can control what is written to the copy pools. If your DB is growing, be sure you are running expiration. Also reclamation should be run on a regular schedule. Andy Huebner -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Capo Sent: Friday, October 15, 2010 3: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. +-- This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.
Re: TSM + VTL and physical tape library
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/ 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
Re: TSM + VTL and physical tape library
Capo, I implement and support both large and small environments with VTLs, and have had a lot of practice. I will weigh in on your questions, but there are more issues involved to really get the best design for your sitation. Contact me offline if you want to discuss further. 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? No, the TSM database contains all backup objects, no matter what storage pool they are in. If a copy storage pool is made, the database keeps track of those objects, too. 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 ? You have a few choices here, depending on how much VTL disk you can afford, and your requirements: - If your virtual library is sized large enough, you can keep all your Primary data on the VTL. A physical library is used for copy storage pools for offsite storage, and backups of the TSM database. - The VTL can be used for multiple storage pools, so some storage pools can hold client data that never migrates to tape (the VERY important clients) and other clients can migrate to tape so the VTL doesn't get full. - If your VTL can't hold all your primary data, you can set up automatic migration. You can set up the storage pool to only migrate data after it is a certain number of days old. - You can also set up a storage pool so the data keeps the most recent version of each file on the VTL, and only migrates to tape the older version. 3. Any real life experience to share ? The candidates for this project are Centricstor and DXi 7500 (or the new DXi 8500). I can't claim personal knowledge of either of those products; I am most familiar with the EMC Disk Library. Neither of those products is one of the major VTLs, but that doesn't mean they won't work. But when evaluating any of these VTLs, consider the possibility of an outage in your design. In other words, if you have problems with your VTL and it is down for awhile, what is your contingency plan? If you have a VTL from a major vendor with good support in your town, you may never experience an outage of more than a few hours. If you buy a low-end product with no local support, you could be down for days when that happens. You may be able to live with that risk, but you should discuss it in advance. Do you need a couple TBs of disk on standby somewhere, so you can use it for disk storage pool so you don't loose backups if the VTL is down? Can your customers live through a long period of time when nothing can be restored because the VTL is down? These are the things that cause customers to buy the high-end products with good hardware support capabilities. Consider the costs/benefits of what each vendor offers, not just in price and performance, but in support. Because one day your are going to need it. Best Regards, John D. Schneider The Computer Coaching Community, LLC; a TSM Consulting Company Office: (314) 635-5424 / Toll Free: (866) 796-9226 Cell: (314) 750-8721 Original Message Subject: [ADSM-L] TSM + VTL and physical tape library From: Capo tsm-fo...@backupcentral.com Date: Fri, October 15, 2010 3:35 am To: ADSM-L@VM.MARIST.EDU 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
