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:[email protected]] De la part de >> Kelly J. Lipp >> Envoyi : 21 juin 2011 13:44 >> @ : [email protected] >> 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:[email protected]] On Behalf Of > ritchi64 > Sent: Tuesday, June 21, 2011 11:33 AM > To: [email protected] > 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 [email protected] via Backup Central. >> |Forward SPAM to [email protected]. >> +---------------------------------------------------------------------- > > -- >> Met vriendelijke groeten/Kind Regards, > >> Remco Post >> [email protected] > > > 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 [email protected] via Backup Central. > |Forward SPAM to [email protected]. > +---------------------------------------------------------------------- > > +---------------------------------------------------------------------- > |This was sent by [email protected] via Backup Central. > |Forward SPAM to [email protected]. > +---------------------------------------------------------------------- -- Met vriendelijke groeten/Kind Regards, Remco Post [email protected] +31 6 248 21 622
