TSM/HSM
Good Morning, I am adding a new LTO3, 3310 library for use with HSM to replace the current LTO2 library. The question I have is can you add a second library for use by HSM so I can migrate the data off the LTO2's to the new LTO3's? If yes, what are the best practices to do so? Thanks Vince
TSM policy
hello group, I have to implement TSM server. The client actual policy is keep everything for 2 months and a month copy for a year (standart) and 3 or 5 years fore some spicial request. What will be te best way to do that without using to much tape. TSM server is 6.1.4 and client active data is ~500 TB. He has actualy ~2PB of data on tape (to much). +-- |This was sent by alainrich...@hotmail.com via Backup Central. |Forward SPAM to ab...@backupcentral.com. +--
Re: TSM policy
Use the TSM Archive function for exceptional data retention which does not constitute regular backups. Richard Sims
Re: TSM/HSM
On 21 jun 2011, at 17:04, D'Antonio III, Vincent E (N-Aerotek) wrote: Good Morning, I am adding a new LTO3, 3310 library for use with HSM to replace the current LTO2 library. The question I have is can you add a second library for use by HSM so I can migrate the data off the LTO2's to the new LTO3's? If yes, what are the best practices to do so? def libr lto3lib def path ... def dr ... def dev lto3dev devt=lto libr=lto3lib def stg lto3pool lto3dev maxscr=1000 upd stg lto2pool next=lto3pool reclaimstg=lto3pool and the migrate and/or reclaim the lto2pool for details, RTFM :) Thanks Vince -- Met vriendelijke groeten/Kind Regards, Remco Post r.p...@plcs.nl +31 6 248 21 622
Re: TSM policy
On 21 jun 2011, at 17:45, ritchi64 wrote: hello group, I have to implement TSM server. The client actual policy is keep everything for 2 months and a month copy for a year (standart) and 3 or 5 years fore some spicial request. What will be te best way to do that without using to much tape. TSM server is 6.1.4 and client active data is ~500 TB. He has actualy ~2PB of data on tape (to much). if you have to ask these questions for such a large environment, I'd suggest finding a real TSM specialist. Somebody who is not afraid to tell the customer what sensible backup policies are, and what the difference between a backup and an archive is. +-- |This was sent by alainrich...@hotmail.com via Backup Central. |Forward SPAM to ab...@backupcentral.com. +-- -- Met vriendelijke groeten/Kind Regards, Remco Post r.p...@plcs.nl +31 6 248 21 622
TSM policy
Humm! What about the policy at your site? Can you share something useful? On 21 jun 2011, at 19:45, remco wrote: if you have to ask these questions for such a large environment, I'd suggest finding a real TSM specialist. Somebody who is not afraid to tell the customer what sensible backup policies are, and what the difference between a backup and an archive is. +-- |This was sent by alainrich...@hotmail.com via Backup Central. |Forward SPAM to ab...@backupcentral.com. +-- -- Met vriendelijke groeten/Kind Regards, Remco Post r.p...@plcs.nl On 21 jun 2011, at 17:45, ritchi64 wrote: hello group, I have to implement TSM server. The client actual policy is keep everything for 2 months and a month copy for a year (standart) and 3 or 5 years fore some spicial request. What will be te best way to do that without using to much tape. TSM server is 6.1.4 and client active data is ~500 TB. He has actualy ~2PB of data on tape (to much). +-- |This was sent by alainrich...@hotmail.com via Backup Central. |Forward SPAM to ab...@backupcentral.com. +--
Re: TSM policy
What Remco is saying that the discussion is much more complicated than the simple strategy they are currently using. If they have so much data on tape now, keeping the same strategy will keep too much data on tape in the future too. So something must change. Keeping a month end copy doesn't really address the business requirements for archive. A more complete conversation that includes stake holders and compliance folks is required to narrow the data down. And since you are now using TSM the typical keep the month end stuff just doesn't really play as TSM doesn't work like the old product did. Trying to implement that strategy with TSM is very costly in both time and resources and still doesn't yield anything truly useful to the business. It's a back to the drawing board of determining actual business requirements before trying to implement. It's there where additional expertise is useful. Kelly J. Lipp Elbert Colorado 719-531-5574 -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of ritchi64 Sent: Tuesday, June 21, 2011 11:33 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM policy Humm! What about the policy at your site? Can you share something useful? On 21 jun 2011, at 19:45, remco wrote: if you have to ask these questions for such a large environment, I'd suggest finding a real TSM specialist. Somebody who is not afraid to tell the customer what sensible backup policies are, and what the difference between a backup and an archive is. +-- |This was sent by alainrich...@hotmail.com via Backup Central. |Forward SPAM to ab...@backupcentral.com. +-- -- Met vriendelijke groeten/Kind Regards, Remco Post r.p...@plcs.nl On 21 jun 2011, at 17:45, ritchi64 wrote: hello group, I have to implement TSM server. The client actual policy is keep everything for 2 months and a month copy for a year (standart) and 3 or 5 years fore some spicial request. What will be te best way to do that without using to much tape. TSM server is 6.1.4 and client active data is ~500 TB. He has actualy ~2PB of data on tape (to much). +-- |This was sent by alainrich...@hotmail.com via Backup Central. |Forward SPAM to ab...@backupcentral.com. +--
Deduplication and Collocation
Hello, I had a student ask me today What happens if you have collocation turned on for a storage pool that you are deduplicating? I did not know what to answer because in my mind I thought well, if the data is collocated then I need to have a copy of that data on that client's tape, otherwise I am going to be mounting another client's tape to get back a de-duped piece of data which would negate the collocation I'm looking at the redbooks for this but I only see 6.1 and in 6.2 they added client side dedup as well (which I also have questions about) Can anyone shed some light on this? Thanks! Mooney
Re: Deduplication and Collocation
Tape pools are not de-duped, so that is not a consideration. On Tue, Jun 21, 2011 at 13:17, Mark Mooney mmoo...@aisconsulting.net wrote: Hello, I had a student ask me today What happens if you have collocation turned on for a storage pool that you are deduplicating? I did not know what to answer because in my mind I thought well, if the data is collocated then I need to have a copy of that data on that client's tape, otherwise I am going to be mounting another client's tape to get back a de-duped piece of data which would negate the collocation I'm looking at the redbooks for this but I only see 6.1 and in 6.2 they added client side dedup as well (which I also have questions about) Can anyone shed some light on this? Thanks! Mooney -- Andy Carlson --- Gamecube:$150,PSO:$50,Broadband Adapter: $35, Hunters License: $8.95/month, The feeling of seeing the red box with the item you want in it:Priceless.
Re: Deduplication and Collocation
Doesn't it undup when it goes to tape? Or am I still living in 5.5 and thinking in VTL dedup? -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Mark Mooney Sent: Tuesday, June 21, 2011 2:17 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Deduplication and Collocation Hello, I had a student ask me today What happens if you have collocation turned on for a storage pool that you are deduplicating? I did not know what to answer because in my mind I thought well, if the data is collocated then I need to have a copy of that data on that client's tape, otherwise I am going to be mounting another client's tape to get back a de-duped piece of data which would negate the collocation I'm looking at the redbooks for this but I only see 6.1 and in 6.2 they added client side dedup as well (which I also have questions about) Can anyone shed some light on this? Thanks! Mooney 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.
Re: Deduplication and Collocation
So data is deduplicated in a disk storage pool but when it is written to tape the entire reconstructed file is written out? Is this the same for file device classes? -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Andrew Carlson Sent: Tuesday, June 21, 2011 8:22 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: Deduplication and Collocation Tape pools are not de-duped, so that is not a consideration. On Tue, Jun 21, 2011 at 13:17, Mark Mooney mmoo...@aisconsulting.net wrote: Hello, I had a student ask me today What happens if you have collocation turned on for a storage pool that you are deduplicating? I did not know what to answer because in my mind I thought well, if the data is collocated then I need to have a copy of that data on that client's tape, otherwise I am going to be mounting another client's tape to get back a de-duped piece of data which would negate the collocation I'm looking at the redbooks for this but I only see 6.1 and in 6.2 they added client side dedup as well (which I also have questions about) Can anyone shed some light on this? Thanks! Mooney -- Andy Carlson --- Gamecube:$150,PSO:$50,Broadband Adapter: $35, Hunters License: $8.95/month, The feeling of seeing the red box with the item you want in it:Priceless.
TSM policy
Ok then, I will add some detail to the case, The client as a 10 years restore service level that said, he can restore everything that was present every night for 2 months. After that, he can restore only the files that were present at the first friday of the month for a year. Two years ago a TSM specialist replace old backup software by TSM. he use keep everything for 400 days to comply with the client service level. Now we got 2 PB of data on tape. And it's getting worse with more and more VMware machine. Now we like to move closer to the service level ask by the client and/or slim the backup process weight. And yes, in some case, we use archive but it's not suit for every Recherche depatment who work on long time data, stop and restart some year after. Destroying data by mistake and not knowing for year that they still need it. -Message d'origine- De : ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] De la part de Kelly J. Lipp Envoyi : 21 juin 2011 13:44 @ : ADSM-L@VM.MARIST.EDU Objet : Re: [ADSM-L] TSM policy What Remco is saying that the discussion is much more complicated than the simple strategy they are currently using. If they have so much data on tape now, keeping the same strategy will keep too much data on tape in the future too. So something must change. Keeping a month end copy doesn't really address the business requirements for archive. A more complete conversation that includes stake holders and compliance folks is required to narrow the data down. And since you are now using TSM the typical keep the month end stuff just doesn't really play as TSM doesn't work like the old product did. Trying to implement that strategy with TSM is very costly in both time and resources and still doesn't yield anything truly useful to the business. It's a back to the drawing board of determining actual business requirements before trying to implement. It's there where additional expertise is useful. Kelly J. Lipp Elbert Colorado 719-531-5574 -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of ritchi64 Sent: Tuesday, June 21, 2011 11:33 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM policy Humm! What about the policy at your site? Can you share something useful? On 21 jun 2011, at 19:45, remco wrote: if you have to ask these questions for such a large environment, I'd suggest finding a real TSM specialist. Somebody who is not afraid to tell the customer what sensible backup policies are, and what the difference between a backup and an archive is. +-- |This was sent by alainrich...@hotmail.com via Backup Central. |Forward SPAM to ab...@backupcentral.com. +-- -- Met vriendelijke groeten/Kind Regards, Remco Post r.p...@plcs.nl On 21 jun 2011, at 17:45, ritchi64 wrote: hello group, I have to implement TSM server. The client actual policy is keep everything for 2 months and a month copy for a year (standart) and 3 or 5 years fore some spicial request. What will be te best way to do that without using to much tape. TSM server is 6.1.4 and client active data is ~500 TB. He has actualy ~2PB of data on tape (to much). +-- |This was sent by alainrich...@hotmail.com via Backup Central. |Forward SPAM to ab...@backupcentral.com. +-- +-- |This was sent by alainrich...@hotmail.com via Backup Central. |Forward SPAM to ab...@backupcentral.com. +--
Re: Deduplication and Collocation
Dedup only works in TSM storage pools that reside on disk (specifically devtype=FILE pools). If you have data that goes to a dedup pool, then gets migrated off to tape, it is reduped (rehydrated, reinflated, whatever you want to call it.) So collocation will still be in effect for that pool. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Mark Mooney Sent: Tuesday, June 21, 2011 2:17 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Deduplication and Collocation Hello, I had a student ask me today What happens if you have collocation turned on for a storage pool that you are deduplicating? I did not know what to answer because in my mind I thought well, if the data is collocated then I need to have a copy of that data on that client's tape, otherwise I am going to be mounting another client's tape to get back a de-duped piece of data which would negate the collocation I'm looking at the redbooks for this but I only see 6.1 and in 6.2 they added client side dedup as well (which I also have questions about) Can anyone shed some light on this? Thanks! Mooney
Re: Deduplication and Collocation
If it is a file device class with dedup turned off, yes. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Mark Mooney Sent: Tuesday, June 21, 2011 2:29 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Deduplication and Collocation So data is deduplicated in a disk storage pool but when it is written to tape the entire reconstructed file is written out? Is this the same for file device classes? -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Andrew Carlson Sent: Tuesday, June 21, 2011 8:22 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: Deduplication and Collocation Tape pools are not de-duped, so that is not a consideration. On Tue, Jun 21, 2011 at 13:17, Mark Mooney mmoo...@aisconsulting.net wrote: Hello, I had a student ask me today What happens if you have collocation turned on for a storage pool that you are deduplicating? I did not know what to answer because in my mind I thought well, if the data is collocated then I need to have a copy of that data on that client's tape, otherwise I am going to be mounting another client's tape to get back a de-duped piece of data which would negate the collocation I'm looking at the redbooks for this but I only see 6.1 and in 6.2 they added client side dedup as well (which I also have questions about) Can anyone shed some light on this? Thanks! Mooney -- Andy Carlson --- Gamecube:$150,PSO:$50,Broadband Adapter: $35, Hunters License: $8.95/month, The feeling of seeing the red box with the item you want in it:Priceless.
Re: Deduplication and Collocation
And that's why storage pool planning is very important. The less re-duping, hydrating, inflating you do the better. Client data to a non-deduped (I guess that would be a duped) pool that migrates to a deduped pool. But backup stgpool before the migration happens to avoid the re. This is where I expect I'll be corrected: as long as the backup stg happens before the deduplication process on the file devtype storage pool the reduping won't have to happen. (we weren't really talking about collocated copy pools were we?) But then you wouldn't have a file devtype pool migrating to tape very often anyway would you? And if you did, that would only be in an emergency situation (i.e., you ran out of room on disk). And in that case why would you collocate? Ah, the words of someone that used to think he knew what he was talking about! Kelly J. Lipp Elbert Colorado 719-531-5574 -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Prather, Wanda Sent: Tuesday, June 21, 2011 12:27 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Deduplication and Collocation Dedup only works in TSM storage pools that reside on disk (specifically devtype=FILE pools). If you have data that goes to a dedup pool, then gets migrated off to tape, it is reduped (rehydrated, reinflated, whatever you want to call it.) So collocation will still be in effect for that pool. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Mark Mooney Sent: Tuesday, June 21, 2011 2:17 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Deduplication and Collocation Hello, I had a student ask me today What happens if you have collocation turned on for a storage pool that you are deduplicating? I did not know what to answer because in my mind I thought well, if the data is collocated then I need to have a copy of that data on that client's tape, otherwise I am going to be mounting another client's tape to get back a de-duped piece of data which would negate the collocation I'm looking at the redbooks for this but I only see 6.1 and in 6.2 they added client side dedup as well (which I also have questions about) Can anyone shed some light on this? Thanks! Mooney
Re: Deduplication and Collocation
Cool, Thanks :) I have questions about client dedup. Do you know of any redbook detail on that? Thanks, Mooney Prather, Wanda wprat...@icfi.com wrote: Dedup only works in TSM storage pools that reside on disk (specifically devtype=FILE pools). If you have data that goes to a dedup pool, then gets migrated off to tape, it is reduped (rehydrated, reinflated, whatever you want to call it.) So collocation will still be in effect for that pool. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Mark Mooney Sent: Tuesday, June 21, 2011 2:17 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Deduplication and Collocation Hello, I had a student ask me today What happens if you have collocation turned on for a storage pool that you are deduplicating? I did not know what to answer because in my mind I thought well, if the data is collocated then I need to have a copy of that data on that client's tape, otherwise I am going to be mounting another client's tape to get back a de-duped piece of data which would negate the collocation I'm looking at the redbooks for this but I only see 6.1 and in 6.2 they added client side dedup as well (which I also have questions about) Can anyone shed some light on this? Thanks! Mooney
Re: Deduplication and Collocation
https://www-304.ibm.com/support/docview.wss?context=SSGSG7lang=allrs=2077wv=1loc=en_UScs=UTF-8uid=swg27018576q1=tste_webcastdc=DA410 -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Mark Mooney Sent: Tuesday, June 21, 2011 2:53 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Deduplication and Collocation Cool, Thanks :) I have questions about client dedup. Do you know of any redbook detail on that? Thanks, Mooney Prather, Wanda wprat...@icfi.com wrote: Dedup only works in TSM storage pools that reside on disk (specifically devtype=FILE pools). If you have data that goes to a dedup pool, then gets migrated off to tape, it is reduped (rehydrated, reinflated, whatever you want to call it.) So collocation will still be in effect for that pool. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Mark Mooney Sent: Tuesday, June 21, 2011 2:17 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Deduplication and Collocation Hello, I had a student ask me today What happens if you have collocation turned on for a storage pool that you are deduplicating? I did not know what to answer because in my mind I thought well, if the data is collocated then I need to have a copy of that data on that client's tape, otherwise I am going to be mounting another client's tape to get back a de-duped piece of data which would negate the collocation I'm looking at the redbooks for this but I only see 6.1 and in 6.2 they added client side dedup as well (which I also have questions about) Can anyone shed some light on this? Thanks! Mooney
Re: TSM policy
On 21 jun 2011, at 20:32, ritchi64 wrote: Ok then, I will add some detail to the case, The client as a 10 years restore service level that said, he can restore everything that was present every night for 2 months. After that, he can restore only the files that were present at the first friday of the month for a year. this is typical for customers who've never heard of TSM. Two years ago a TSM specialist replace old backup software by TSM. he use keep everything for 400 days to comply with the client service level. Now we got 2 PB of data on tape. And it's getting worse with more and more VMware machine. That was some lousy TSM specialist, or a typical sales job... giving the customer what he asks for rather than what he needs. Now we like to move closer to the service level ask by the client and/or slim the backup process weight. And yes, in some case, we use archive but it's not suit for every Recherche depatment who work on long time data, stop and restart some year after. Destroying data by mistake and not knowing for year that they still need it. indeed, we have now some detail, but by a long stretch not enough de design a proper solution. There are so many variables, that I have no idea where to begin. You'll probably need a few weeks of TSM architect/engineer just to design the policies and select the right tools for the job. -Message d'origine- De : ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] De la part de Kelly J. Lipp Envoyi : 21 juin 2011 13:44 @ : ADSM-L@VM.MARIST.EDU Objet : Re: [ADSM-L] TSM policy What Remco is saying that the discussion is much more complicated than the simple strategy they are currently using. If they have so much data on tape now, keeping the same strategy will keep too much data on tape in the future too. So something must change. Keeping a month end copy doesn't really address the business requirements for archive. A more complete conversation that includes stake holders and compliance folks is required to narrow the data down. And since you are now using TSM the typical keep the month end stuff just doesn't really play as TSM doesn't work like the old product did. Trying to implement that strategy with TSM is very costly in both time and resources and still doesn't yield anything truly useful to the business. It's a back to the drawing board of determining actual business requirements before trying to implement. It's there where additional expertise is useful. Kelly J. Lipp Elbert Colorado 719-531-5574 -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of ritchi64 Sent: Tuesday, June 21, 2011 11:33 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM policy Humm! What about the policy at your site? Can you share something useful? On 21 jun 2011, at 19:45, remco wrote: if you have to ask these questions for such a large environment, I'd suggest finding a real TSM specialist. Somebody who is not afraid to tell the customer what sensible backup policies are, and what the difference between a backup and an archive is. +-- |This was sent by alainrich...@hotmail.com via Backup Central. |Forward SPAM to ab...@backupcentral.com. +-- -- Met vriendelijke groeten/Kind Regards, Remco Post r.p...@plcs.nl On 21 jun 2011, at 17:45, ritchi64 wrote: hello group, I have to implement TSM server. The client actual policy is keep everything for 2 months and a month copy for a year (standart) and 3 or 5 years fore some spicial request. What will be te best way to do that without using to much tape. TSM server is 6.1.4 and client active data is ~500 TB. He has actualy ~2PB of data on tape (to much). +-- |This was sent by alainrich...@hotmail.com via Backup Central. |Forward SPAM to ab...@backupcentral.com. +-- +-- |This was sent by alainrich...@hotmail.com via Backup Central. |Forward SPAM to ab...@backupcentral.com. +-- -- Met vriendelijke groeten/Kind Regards, Remco Post r.p...@plcs.nl +31 6 248 21 622
Re: TSM policy
Makes perfect sense. However, as you've observed, the cost is too high. What is required now is a rationalization of the data. Clearly (at least to those outside the business) not all of the stuff captured in a backup may be required in the future. You mention VMs. Most of what's in a VM container isn't useful from a business standpoint. What that means is you must start to use the TSM archive function to parry out just the data in those VMs that you must keep for a long time. This is not easy! It means actually understanding the data itself and how it applies to the long term retention requirements based on business needs or compliance with regulations. Sometimes this can be done based on file types: for instance all MS Word documents must be kept for seven years. Sometimes it can be by server: all of the data on this machine, except OS stuff, must be kept for five years. There really isn't an inexpensive and efficient way to do this otherwise. You can certainly archive everything forever, but you already know what that costs. There is not a simple answer to your original question. You must step back and take a different approach. The reason the original approach has worked so far is the amount of data you had up until now was reasonable. Now the amount is unreasonable. The problem is simple. The solution is not. Sometimes having a 50 mile expert work with you to analyze the data and teach the organization how archiving should work is the only way to get it done. I know that's what Remco had in mind. He and I have worked together for years! Again, having that expert is difficult and it requires a commitment on your organization's part to achieve real change. The definition of insanity is doing the same thing over and over and expecting different results... Kelly J. Lipp Elbert Colorado 719-531-5574 -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of ritchi64 Sent: Tuesday, June 21, 2011 12:32 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM policy Ok then, I will add some detail to the case, The client as a 10 years restore service level that said, he can restore everything that was present every night for 2 months. After that, he can restore only the files that were present at the first friday of the month for a year. Two years ago a TSM specialist replace old backup software by TSM. he use keep everything for 400 days to comply with the client service level. Now we got 2 PB of data on tape. And it's getting worse with more and more VMware machine. Now we like to move closer to the service level ask by the client and/or slim the backup process weight. And yes, in some case, we use archive but it's not suit for every Recherche depatment who work on long time data, stop and restart some year after. Destroying data by mistake and not knowing for year that they still need it. -Message d'origine- De : ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] De la part de Kelly J. Lipp Envoyi : 21 juin 2011 13:44 @ : ADSM-L@VM.MARIST.EDU Objet : Re: [ADSM-L] TSM policy What Remco is saying that the discussion is much more complicated than the simple strategy they are currently using. If they have so much data on tape now, keeping the same strategy will keep too much data on tape in the future too. So something must change. Keeping a month end copy doesn't really address the business requirements for archive. A more complete conversation that includes stake holders and compliance folks is required to narrow the data down. And since you are now using TSM the typical keep the month end stuff just doesn't really play as TSM doesn't work like the old product did. Trying to implement that strategy with TSM is very costly in both time and resources and still doesn't yield anything truly useful to the business. It's a back to the drawing board of determining actual business requirements before trying to implement. It's there where additional expertise is useful. Kelly J. Lipp Elbert Colorado 719-531-5574 -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of ritchi64 Sent: Tuesday, June 21, 2011 11:33 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM policy Humm! What about the policy at your site? Can you share something useful? On 21 jun 2011, at 19:45, remco wrote: if you have to ask these questions for such a large environment, I'd suggest finding a real TSM specialist. Somebody who is not afraid to tell the customer what sensible backup policies are, and what the difference between a backup and an archive is. +-- |This was sent by alainrich...@hotmail.com via Backup Central. |Forward SPAM to ab...@backupcentral.com. +-- -- Met vriendelijke groeten/Kind Regards, Remco Post r.p...@plcs.nl On 21 jun 2011, at 17:45, ritchi64 wrote:
Re: Deduplication and Collocation
Even if a FILE devclass has dedup turned on, when the data is migrated, reclaimed, or backed up (backup stgpool) to tape, then the files are reconstructed from their pieces. You cannot dedup on DISK stgpools. DISK implies random access disk - e.g., devclass DISK. FILE implies serial access disk - e.g., devclass FILE. But I think there is still an open question about collocation and deduplication. Deduplication must be done using FILE stgpools, but FILE stgpools CAN use collocation. I don't know what happens in this case. ..Paul At 02:38 PM 6/21/2011, Prather, Wanda wrote: If it is a file device class with dedup turned off, yes. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Mark Mooney Sent: Tuesday, June 21, 2011 2:29 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Deduplication and Collocation So data is deduplicated in a disk storage pool but when it is written to tape the entire reconstructed file is written out? Is this the same for file device classes? -- Paul ZarnowskiPh: 607-255-4757 Manager, Storage Services Fx: 607-255-8521 719 Rhodes Hall, Ithaca, NY 14853-3801Em: p...@cornell.edu
Re: Deduplication and Collocation
Thank you Wanda! Much Appreciated! -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Prather, Wanda Sent: Tuesday, June 21, 2011 9:09 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: Deduplication and Collocation https://www-304.ibm.com/support/docview.wss?context=SSGSG7lang=allrs=2077wv=1loc=en_UScs=UTF-8uid=swg27018576q1=tste_webcastdc=DA410 -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Mark Mooney Sent: Tuesday, June 21, 2011 2:53 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Deduplication and Collocation Cool, Thanks :) I have questions about client dedup. Do you know of any redbook detail on that? Thanks, Mooney Prather, Wanda wprat...@icfi.com wrote: Dedup only works in TSM storage pools that reside on disk (specifically devtype=FILE pools). If you have data that goes to a dedup pool, then gets migrated off to tape, it is reduped (rehydrated, reinflated, whatever you want to call it.) So collocation will still be in effect for that pool. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Mark Mooney Sent: Tuesday, June 21, 2011 2:17 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Deduplication and Collocation Hello, I had a student ask me today What happens if you have collocation turned on for a storage pool that you are deduplicating? I did not know what to answer because in my mind I thought well, if the data is collocated then I need to have a copy of that data on that client's tape, otherwise I am going to be mounting another client's tape to get back a de-duped piece of data which would negate the collocation I'm looking at the redbooks for this but I only see 6.1 and in 6.2 they added client side dedup as well (which I also have questions about) Can anyone shed some light on this? Thanks! Mooney
TSM policy
Ok then remco, 1- What do you think about using two TSM instance on the same backup server. One for every day short term retention and an other one for the long term once a month. 2- Somebody suggest only one instance but use the undelete option for long term retention. I think it will get lot more unneeded data. On 21 jun 2011, at 21:32, remco wrote: On 21 jun 2011, at 20:32, ritchi64 wrote: Ok then, I will add some detail to the case, The client as a 10 years restore service level that said, he can restore everything that was present every night for 2 months. After that, he can restore only the files that were present at the first friday of the month for a year. this is typical for customers who've never heard of TSM. Two years ago a TSM specialist replace old backup software by TSM. he use keep everything for 400 days to comply with the client service level. Now we got 2 PB of data on tape. And it's getting worse with more and more VMware machine. That was some lousy TSM specialist, or a typical sales job... giving the customer what he asks for rather than what he needs. Now we like to move closer to the service level ask by the client and/or slim the backup process weight. And yes, in some case, we use archive but it's not suit for every Recherche depatment who work on long time data, stop and restart some year after. Destroying data by mistake and not knowing for year that they still need it. indeed, we have now some detail, but by a long stretch not enough de design a proper solution. There are so many variables, that I have no idea where to begin. You'll probably need a few weeks of TSM architect/engineer just to design the policies and select the right tools for the job. -Message d'origine- De : ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] De la part de Kelly J. Lipp Envoyi : 21 juin 2011 13:44 @ : ADSM-L@VM.MARIST.EDU Objet : Re: [ADSM-L] TSM policy What Remco is saying that the discussion is much more complicated than the simple strategy they are currently using. If they have so much data on tape now, keeping the same strategy will keep too much data on tape in the future too. So something must change. Keeping a month end copy doesn't really address the business requirements for archive. A more complete conversation that includes stake holders and compliance folks is required to narrow the data down. And since you are now using TSM the typical keep the month end stuff just doesn't really play as TSM doesn't work like the old product did. Trying to implement that strategy with TSM is very costly in both time and resources and still doesn't yield anything truly useful to the business. It's a back to the drawing board of determining actual business requirements before trying to implement. It's there where additional expertise is useful. Kelly J. Lipp Elbert Colorado 719-531-5574 -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of ritchi64 Sent: Tuesday, June 21, 2011 11:33 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM policy Humm! What about the policy at your site? Can you share something useful? On 21 jun 2011, at 19:45, remco wrote: if you have to ask these questions for such a large environment, I'd suggest finding a real TSM specialist. Somebody who is not afraid to tell the customer what sensible backup policies are, and what the difference between a backup and an archive is. + +-- |This was sent by alainrich...@hotmail.com via Backup Central. |Forward SPAM to ab...@backupcentral.com. + +-- -- Met vriendelijke groeten/Kind Regards, Remco Post r.p...@plcs.nl On 21 jun 2011, at 17:45, ritchi64 wrote: hello group, I have to implement TSM server. The client actual policy is keep everything for 2 months and a month copy for a year (standart) and 3 or 5 years fore some spicial request. What will be te best way to do that without using to much tape. TSM server is 6.1.4 and client active data is ~500 TB. He has actualy ~2PB of data on tape (to much). +- +- |This was sent by alainrich...@hotmail.com via Backup Central. Forward |SPAM to ab...@backupcentral.com. +- +- +- +- |This was sent by alainrich...@hotmail.com via Backup Central. Forward |SPAM to ab...@backupcentral.com. +- +- -- Met vriendelijke groeten/Kind Regards, Remco Post r.p...@plcs.nl +-- |This was sent by alainrich...@hotmail.com via Backup Central. |Forward SPAM to
Re: TSM policy
On 21 jun 2011, at 21:38, ritchi64 wrote: Ok then remco, 1- What do you think about using two TSM instance on the same backup server. One for every day short term retention and an other one for the long term once a month. 10 days at 1250 euro/day plus expenses and you'll find out ;-) Seriously, I have no thoughts on this whatsoever, frankly because I only know about 1% of the story, which is for me just enough to tell you that I have not enough information to have any thoughts. 2- Somebody suggest only one instance but use the undelete option for long term retention. I think it will get lot more unneeded data. If that somebody suggests that undelete is some TSM feature, I'd like to hear from that somebody and explain to me how that works. ;-) On 21 jun 2011, at 21:32, remco wrote: On 21 jun 2011, at 20:32, ritchi64 wrote: Ok then, I will add some detail to the case, The client as a 10 years restore service level that said, he can restore everything that was present every night for 2 months. After that, he can restore only the files that were present at the first friday of the month for a year. this is typical for customers who've never heard of TSM. Two years ago a TSM specialist replace old backup software by TSM. he use keep everything for 400 days to comply with the client service level. Now we got 2 PB of data on tape. And it's getting worse with more and more VMware machine. That was some lousy TSM specialist, or a typical sales job... giving the customer what he asks for rather than what he needs. Now we like to move closer to the service level ask by the client and/or slim the backup process weight. And yes, in some case, we use archive but it's not suit for every Recherche depatment who work on long time data, stop and restart some year after. Destroying data by mistake and not knowing for year that they still need it. indeed, we have now some detail, but by a long stretch not enough de design a proper solution. There are so many variables, that I have no idea where to begin. You'll probably need a few weeks of TSM architect/engineer just to design the policies and select the right tools for the job. -Message d'origine- De : ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] De la part de Kelly J. Lipp Envoyi : 21 juin 2011 13:44 @ : ADSM-L@VM.MARIST.EDU Objet : Re: [ADSM-L] TSM policy What Remco is saying that the discussion is much more complicated than the simple strategy they are currently using. If they have so much data on tape now, keeping the same strategy will keep too much data on tape in the future too. So something must change. Keeping a month end copy doesn't really address the business requirements for archive. A more complete conversation that includes stake holders and compliance folks is required to narrow the data down. And since you are now using TSM the typical keep the month end stuff just doesn't really play as TSM doesn't work like the old product did. Trying to implement that strategy with TSM is very costly in both time and resources and still doesn't yield anything truly useful to the business. It's a back to the drawing board of determining actual business requirements before trying to implement. It's there where additional expertise is useful. Kelly J. Lipp Elbert Colorado 719-531-5574 -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of ritchi64 Sent: Tuesday, June 21, 2011 11:33 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM policy Humm! What about the policy at your site? Can you share something useful? On 21 jun 2011, at 19:45, remco wrote: if you have to ask these questions for such a large environment, I'd suggest finding a real TSM specialist. Somebody who is not afraid to tell the customer what sensible backup policies are, and what the difference between a backup and an archive is. + +-- |This was sent by alainrich...@hotmail.com via Backup Central. |Forward SPAM to ab...@backupcentral.com. + +-- -- Met vriendelijke groeten/Kind Regards, Remco Post r.p...@plcs.nl On 21 jun 2011, at 17:45, ritchi64 wrote: hello group, I have to implement TSM server. The client actual policy is keep everything for 2 months and a month copy for a year (standart) and 3 or 5 years fore some spicial request. What will be te best way to do that without using to much tape. TSM server is 6.1.4 and client active data is ~500 TB. He has actualy ~2PB of data on tape (to much). +- +- |This was sent by alainrich...@hotmail.com via Backup Central. Forward |SPAM to ab...@backupcentral.com.
Re: TSM policy
What do you think about using two TSM instance on the same backup server. One for every day short term retention and an other one for the long term once a month. I have a customer who does that, because they were bought by a non-US parent company that REQUIREs them to keep a monthly backup forever. It works. -One instance does incrementals with max 60 day retention. -The 2nd instance does an incremental, not a full, on the last weekend of every month. Making the monthly an incremental is the trick to keeping the DB and the backup store a (sort of) reasonable size. With the monthly incremental, you can still restore any client to the point in time, without actually having to back up all that data again. I didn't architect that solution, and my hat is off to the person who did; it meets the requirements imposed on the organization. I still don't recommend it. The truly best solution would be to set up the correct type of archiving software (not TSM archiving), so that the necessary email and documents are saved for eons in a way that is not dependent on the original hostname, not dependent on the original media, and properly indexed and searchable (and not limited to the file name for searches). Trouble is, that takes commitment by the company (and a lot of work and expense up front) to actually implement good records management practices. Most companies won't do that work in the short term, even though they would be better off in the long term.
