Documenting TSM
Starting to document the Installing/Implementing TSM7.1 environment and I'm wondering what type of information and the amount detail others are putting into their docs? How are you documented TSM? Security? Database? Scripts? Installation steps? troubleshooting?installing clients? ...etc. Does anyone have a good documentation example day-to-day operation/administration? -mad
Re: 3584 questions
Hi, Update the deviceclass to new library is the key. But it is important you verify if the label of tapes are the same in both libraries but Tsm thinks the tapes are scratch. Enviado desde Yahoo Mail para Android De:"Paul Zarnowski" Fecha:vie 22 22e may 22e 2015 a las 22:23 Asunto:Re: 3584 questions What Thomas said, only I think he meant to say "3584" everwhere he said "3484". AFAIK, there is no such thing as a 3484. We did a similar thing moving from an ADIC Scalar10K SCSI library to a 3584. As long as the new library has the same library name as the old library, TSM will be fine. At 03:50 PM 5/22/2015, Thomas Denier wrote: >The 3484 is a SCSI library with a mechanical design similar to that of a 3494. >In more recent times IBM has marketed the 3484 or a very similar successor as >the TS3500. > >We used to do what amounted to a 3494 to 3584 migration during disaster >recovery tests; our own system had a 3494, but our hot site vendor provided a >3584. > >I checked our old DR procedure. It does not cover the checkout operation, >since all the volumes available at the test had been checked out and sent to >an offsite vault at some point in the past. In outline the process was as >follows: > >Update 3494 tape drive paths to "online=no". >Execute "define library" for the 3484. >Execute the related "define drive" and "define path" commands (including >defining a path to the library). >Update tape device classes to use the new library. >Check volumes into the new library. >Execute an "audit library" command with "checklabel=barcode" for the new >library. > >The device for the new server to library path will probably follow a >distinctly different naming convention than its 3494 counterpart. > >Most commands that refer to a library name need somewhat different operands >for a SCSI library (such as a 3484) than for a 3494. You will need to review >any such commands executed as part of your automated housekeeping or as part >of manual procedures such as adding tape volumes. > >Thomas Denier >Thomas Jefferson University > >-Original Message- > >We are looking at replacing our 3494 libraries with 3584s. >Thinkk that is the correct number. > >Are they similar enough that I can simply check out the volumes from the old >libraries and check into the new? > >We are keeping our ts1120 drives and transferring them into the new robots. > >Anyone with experience doing this move? > >Thanks for any help. >The information contained in this transmission contains privileged and >confidential information. It is intended only for the use of the person named >above. If you are not the intended recipient, you are hereby notified that any >review, dissemination, distribution or duplication of this communication is >strictly prohibited. If you are not the intended recipient, please contact the >sender by reply email and destroy all copies of the original message. > >CAUTION: Intended recipients should NOT use email communication for emergent >or urgent health care matters. -- Paul Zarnowski Ph: 607-255-4757 Assistant Director for Storage Services Fx: 607-255-8521 IT at Cornell / Infrastructure Em: p...@cornell.edu 719 Rhodes Hall, Ithaca, NY 14853-3801
Re: Removing obsolete TDP for MySAP files from TSM
Hi Eric, The number of versions to keep is controlled by the MAX_VERSIONS profile parameter. A backup generation consists of one full database backup and associated partial/incremental and redo log backups (no matter how many this may be). If you used the MAX_VERSIONS profile parameter for all backups that you ran, then the deletions should happen transparently. You can use the backfm utility to view all data that is stored in TSM. By pressing 'F6' you can see additional information for each backup, including the version number. If a backup was performed without the MAX_VERSIONS profile parameter, then this backup is considered to be under some other policy and will NOT be deleted by the MAX_VERSIONS processing. Such a backup would be shown by the backfm utility with version number 0. Backups that are under TSM ERP version control will have a number > 0. Del "ADSM: Dist Stor Manager" wrote on 05/22/2015 04:54:46 AM: > From: "Loon, EJ van (ITOPT3) - KLM" > To: ADSM-L@VM.MARIST.EDU > Date: 05/22/2015 04:56 AM > Subject: Removing obsolete TDP for MySAP files from TSM > Sent by: "ADSM: Dist Stor Manager" > > Hi TSM-ers! (or should I say ISP-ers since the product will be > renamed in the near future?)! > We are using TDP for MySAP to back-up our SAP databases. For several > clients I see that files are left behind in TSM which no longer > exist in the SAP repository. > When you backup Oracle by using TDP for Oracle you have a tool > called tdposync which compares the RMAN catalog with TSM and it > allows you to delete files from TSM which are not in RMAN. How does > this work in TDP for MySAP? > Thank you very much for any help in advance! > Kind regards, > Eric van Loon > AF/KLM Storage Engineering > > For information, services and offers, please visit our web site: > http://www.klm.com. This e-mail and any attachment may contain > confidential and privileged material intended for the addressee > only. If you are not the addressee, you are notified that no part of > the e-mail or any attachment may be disclosed, copied or > distributed, and that any other action related to this e-mail or > attachment is strictly prohibited, and may be unlawful. If you have > received this e-mail by error, please notify the sender immediately > by return e-mail, and delete this message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/ > or its employees shall not be liable for the incorrect or incomplete > transmission of this e-mail or any attachments, nor responsible for > any delay in receipt. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > Dutch Airlines) is registered in Amstelveen, The Netherlands, with > registered number 33014286 > >
