George, In a short answer, no not everything is being kept forever. First it looks like the your active, inactive and delete files needs some shoring up. You will not be able to restore any deleted files after the next expiration runs. You will be able to restore files that were changed forever
Based on what you sent. # of different file versions: no limit Files that are modified and in the same location with the same name will be retained forever. ( I have mine set to 10) # of days to keep inactive versions: no limit Previous versions of changed files will be retained forever. ( I have standard set to 30) Deleted versions to keep: 0 Means no files that have been deleted will be retained on tape ( I have mine set to 2) Amount of time to keep the last file version:0 All deleted files will be expired from the tsm server after the next expiration process is run (I have mine set to 90) -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf Of Huebschman, George J. Sent: Tuesday, August 10, 2010 11:44 AM To: [email protected] Subject: Re: NBU guy in TSM shop and I need help You have three questions really. You need numerous tapes for restore because backups write to tape every day. Not every file is on the same tape, unless you use collocation for the storage pool. (Then you need more tapes to backup!) Not every file is going to be deleted every day. So a Point in Time restore, or a restore of all active objects is going to have to access tapes that were written over a span of time. Also, reclamation of tapes impacts where data is kept. As data ages and expires and tapes/data are consolidated, the data moves onto new tapes. TSM doesn't care (unless collocation is in use) what tape the data goes onto. You can accelerate restores by running them in pieces if they are large, and running them from the command line. Second question about retention. Retention has nothing to do with how many tapes your data is on. You are either restoring Active versions, Inactive versions to a point in time (which is going to be the same for all of the objects), or a specific inactive file or files. Except for the fact that the longer the retention, the more tapes there are generally going to be in the storage pool, retention doesn't affect where the specific objects are stored. Are you keeping data forever? I am not sure. Your translation is a little murky. It would be plainer if you used TSM's terms. If Versions Data Deleted AND Retain Extra Versions really is No Limit, then yes, you are keeping things forever. We have some like that: Policy Policy Mgmt Copy Versions Versions Retain Retain Domain Set Name Class Group Data Data Extra Only Name Name Name Exists Deleted Versions Version --------- --------- --------- --------- -------- -------- -------- ------- X-FILES ACTIVE FOREVER STANDARD No Limit No Limit No Limit No Limit Does your CopyGroup look more like this example? Policy Policy Mgmt Copy Versions Versions Retain Retain Domain Set Name Class Group Data Data Extra Only Name Name Name Exists Deleted Versions Version --------- --------- --------- --------- -------- -------- -------- ------- 5_YEAR ACTIVE 1825DAYS STANDARD No Limit No Limit 1,830 1,830 * Versions Data Exists is how many VERSIONS of objects that are Active on the Client may be kept. * Versions Data Deleted (or changed) is how many VERSIONS of objects that are Inactive on the client may be kept. * Retain Extra Versions (TSM never automatically deletes the Active version)is how many DAYS to keep Inactive versions. * Retain Only Version, is how many DAYS to keep the last Inactive version. If I ran backups three times a day, morning, noon, night, I could have three copies of a file daily, if it was changed each time. (For example a very frequent SQL Dump with a timestamp name.) In five years I would accumulate three times 1,830 VERSIONS, but each version would only live 1,830 DAYS. A reason it is good to have VDE and VDD set to No Limit is to avoid busting an requirement to keep data for a specific length of time. In the above example, if the government wanted me to keep data for 1,830 days, and I had my VERSIONS set to 1,830 days, I would be 1,220 days SHORT, because the newest version would bump the oldest version regardless of age. If you are confused by copygroup terminology, you are in good company! George Huebschman Legg Mason Media Librarian -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf Of ego3456 Sent: Tuesday, August 10, 2010 10:54 AM To: [email protected] Subject: [ADSM-L] NBU guy in TSM shop and I need help I'm trying to understand why there are so many tapes required for restore and have started to look at one aspect of our management classes. this is the setup in question: Backup Versions __________________ Days between backups = 0 _______________________ How many different versions of the file should be kept? No limit _________________ Number of days to keep inactive versions No limit _________________________ For backup files that a user has deleted from the client node: Number of file versions to keep This number of versions : 0 _____________________________ Amount of time to keep the last file version This number of days: 0 ________________________ under this configuration is it really keeping all files forever? I'm so lost on this its not funny and the conversion from NBU to TSM seems like going from a working system to a broken system even though i know its just bad configuration that is the cause its becoming hard for me not to throw the baby out with this bathwater and start fresh with a simple NBU system (simple because i know it backward and forward not because its better per se.. i really am trying hard to make this TSM configuration work) Thanks for any help you can give. -eric +---------------------------------------------------------------------- |This was sent by [email protected] via Backup Central. |Forward SPAM to [email protected]. +---------------------------------------------------------------------- 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.
