Using Datadomain for replication
Anyone out there using a DDR as the primary FILE devclass, having it replicate to a 2nd DDR in a recovery site and having to do a TSM recovery using the 2nd DDR? Are you using the UNC path name for the DEVCLASS or a drive mapping? This is strictly Winders and CIFS, not NFS. What I'm coming up against is at the 2nd site after restoring the DB all my volumes still point to the primary DDR UNC name. I can change the DEVCLASS, but that doesn't seem to effect the existing volumes, only new volumes. So unless I also rename the 2nd DDR to the name of the primary DDR, all my volumes are basically unavailable. Just wondering how anyone else using DDR replication for TSM. Bill Boyer DSS, Inc. (610) 927-4407 Enjoy life. It has an expiration date. - ??
Re: Using Datadomain for replication
We are currently building that setup. We use a hosts entry to point to the DD. The untested plan is to use a hosts entry to point the DR TSM to the replicated copy and avoid re-pointing the devclass. Our connectivity is UNC across a private network. We are a month or two from the DR testing. Andy Huebner -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Bill Boyer Sent: Friday, December 09, 2011 9:14 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Using Datadomain for replication Anyone out there using a DDR as the primary FILE devclass, having it replicate to a 2nd DDR in a recovery site and having to do a TSM recovery using the 2nd DDR? Are you using the UNC path name for the DEVCLASS or a drive mapping? This is strictly Winders and CIFS, not NFS. What I'm coming up against is at the 2nd site after restoring the DB all my volumes still point to the primary DDR UNC name. I can change the DEVCLASS, but that doesn't seem to effect the existing volumes, only new volumes. So unless I also rename the 2nd DDR to the name of the primary DDR, all my volumes are basically unavailable. Just wondering how anyone else using DDR replication for TSM. Bill Boyer DSS, Inc. (610) 927-4407 Enjoy life. It has an expiration date. - ?? 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: Using Datadomain for replication
I do have a setup as you describe, but my TSM servers are AIX hosts using NFS mounts to the DDR. In my situation, I just NFS mount up the second DataDomain under the same mount points and the TSM server has no idea that it's from a different DataDomain. Not sure how you would do it with a CIFS mount... sorry. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Bill Boyer Sent: Friday, December 09, 2011 8:14 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Using Datadomain for replication Anyone out there using a DDR as the primary FILE devclass, having it replicate to a 2nd DDR in a recovery site and having to do a TSM recovery using the 2nd DDR? Are you using the UNC path name for the DEVCLASS or a drive mapping? This is strictly Winders and CIFS, not NFS. What I'm coming up against is at the 2nd site after restoring the DB all my volumes still point to the primary DDR UNC name. I can change the DEVCLASS, but that doesn't seem to effect the existing volumes, only new volumes. So unless I also rename the 2nd DDR to the name of the primary DDR, all my volumes are basically unavailable. Just wondering how anyone else using DDR replication for TSM. Bill Boyer DSS, Inc. (610) 927-4407 Enjoy life. It has an expiration date. - ?? The BCI Email Firewall made the following annotations - *Confidentiality Notice: This E-Mail is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you have received this communication in error, please do not distribute, and delete the original message. Thank you for your compliance. You may contact us at: Blue Cross of Idaho 3000 E. Pine Ave. Meridian, Idaho 83642 1.208.345.4550 -
Re: Max File Limitation and other questions
Depending on the client operation, you'll run out of address space if you're on a platform for which IBM only distributes 32-bit BA clients (i.e. x86 Linux). There's ways you can mitigate this (for instance, virtual mount points, memory efficient backup option). We still run into problems around 10-20 million files in a single operation though. -- Skylar Thompson (skyl...@u.washington.edu) -- Genome Sciences Department, System Administrator -- Foege Building S046, (206)-685-7354 -- University of Washington School of Medicine On 12/ 7/11 11:35 AM, Jim Neal wrote: 2) Is there a limit to the number of files the a TSM client can back up? ( I have found an unofficial document that specifies that TSM's HSM product can handle about 100 Million files, but again I can't seem to locate it in IBM's HSM documentation)
