Well I agree about the selection bias :>) But, I have one customer that I've had on V6 since 6.1.2, now on 6.2, 200G DB.
I have 2 others (smaller DB's ) that I've converted from production 5.5 to 6.2, and have no qualms about recommending it to anybody (assuming the server hardware has the required memory). It's been stable for them. -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Robert Clark Sent: Friday, October 14, 2011 3:54 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] vtl versus file systems for pirmary pool The symposium example seems a classic case of selection bias. [RC] Sent from my iPhone On Oct 5, 2011, at 12:14, Remco Post <r.p...@plcs.nl> wrote: > Hi, > > I saw last week that about half of the people visiting the TSM Symposium were > running V6, it's been stable for me so far. > > The likeliness of an accidental SHA1 hash collision is relatively small even > compared to the total number of objects that a TSM server could possibly ever > store during its entire lifetime, insignificant. That being said, if you > think that your data is to valuable to even risk that, don't dedup. > > > -- > > Gr., Remco > > Op 5 okt. 2011 om 19:24 heeft Shawn Drew <shawn.d...@americas.bnpparibas.com> > het volgende geschreven: > >> Along this line, we are still using TSM5.5 Some of the features >> mentioned previously require TSM6. TSM6 still feels risky to me. >> Maybe more risky than a hash collision. >> Just looking for a consensus, Do people think its mature enough now >> that it is as stable/reliable as TSM5 ? >> >> PS. Test restores are the only way to be sure your backups are good. >> You shouldn't just "trust" TSM. >> >> Regards, >> Shawn >> ________________________________________________ >> Shawn Drew >> >> >> >> >> >> Internet >> rrho...@firstenergycorp.com >> >> Sent by: ADSM-L@VM.MARIST.EDU >> 10/05/2011 11:03 AM >> Please respond to >> ADSM-L@VM.MARIST.EDU >> >> >> To >> ADSM-L >> cc >> >> Subject >> Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: >> Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] >> vtl versus file systems for pirmary pool >> >> >> >> >> >> >>> When TSM is duplicating your data (aka backing up storage pools), >>> there is no logical connection between your primary storage pool and >>> your copypool. >> >> Well . . .yes . .. no . . . >> >> All our eggs are in one basket no matter what. The logical >> connection between pri and copy pools is TSM itself. A logical >> corruption in TSM can take out both. Your data could be sitting there >> on tape and completely useless. Yes, that's why we have TSM db >> backups, but are they good? What if there is a TSM bug that renders >> all your backups bad - we don't find out until we need it! >> >> At some point you have to trust something. We all trust TSM. Yes, >> we do the db backup, create pri and copy pools, use reuse delay . . >> .everything to allow for problems . . . but we are still trusting >> that TSM workss as advertised. A really, really paranoid would run >> two complete separate/different backup systems - but who can afford that, or >> want to? >> But then, we do do that for our biggest SAP/ORacle systems. We use >> Oracle/RMAN-to-flasharea/RMAN-to-TDPO/TSM, but we also run EMC/clone >> backups off our DR sites R2's . . but also to TSM. >> >> >> Rick >> >> >> >> >> >> ----------------------------------------- >> The information contained in this message is intended only for the >> personal and confidential use of the recipient(s) named above. If the >> reader of this message is not the intended recipient or an agent >> responsible for delivering it to the intended recipient, you are >> hereby notified that you have received this document in error and >> that any review, dissemination, distribution, or copying of this >> message is strictly prohibited. If you have received this >> communication in error, please notify us immediately, and delete the >> original message. >> >> >> >> This message and any attachments (the "message") is intended solely >> for the addressees and is confidential. If you receive this message >> in error, please delete it and immediately notify the sender. Any use >> not in accord with its purpose, any dissemination or disclosure, >> either whole or partial, is prohibited except formal approval. The >> internet can not guarantee the integrity of this message. BNP PARIBAS >> (and its subsidiaries) shall (will) not therefore be liable for the >> message if modified. Please note that certain functions and services for BNP >> Paribas may be performed by BNP Paribas RCC, Inc.
