Re: TSM User Group for Baltimore/WashingtonDC/NorthernVirginia meets April 30
I would come if I lived closer ;-) But, I am excited to be going to the IBM Developer Works Conference next week in New Orleans. Lots of Planet Tivoli sessions there. see ya, Tommy - Original Message - From: "Prather, Wanda" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, April 04, 2003 9:07 AM Subject: TSM User Group for Baltimore/WashingtonDC/NorthernVirginia meets April 30 > You are invited to join us for the next meeting of TSMUG, the > Baltimore/WashingtonDC/Northern Virginia TSM user's group -- > > Date:April 30, 2003 > Time:8:30 am - 1 pm > Location:Computer Applications Specialists (CAS) > 6201 Chevy Chase Drive > Laurel MD 20707 > > Registration: > Meetings are free and everyone is welcome. > However, you MUST REGISTER in advance. > All that is necessary is to send a message > to [EMAIL PROTECTED] > > (If you haven't been to a meeting before, please > include your company name and a phone number.) > > Cutoff date for registration is noon on April 29. > > You will receive a confirmation email/reminder > notice the week before the meeting. > > For more information, please see our web site: > http://www.jasi.com/TSMUG/index.html > > Agenda below: > > Passport Advantage Explained - Kenneth Chisolm >Are you as confused as we are about Passport Advantage >and how it works? Kenneth will bring us all up to date. > > ITSRM - Michelle M. Adams >ITSRM is a new member of the Tivoli Storage family. >Come and learn how Tivoli Storage Resource Manager >can work in your environment > > Roundtable >Our famous TSM roundtable - Come ask your questions >and share your experiences with TSM. >
Re: Admin schedules
The job is setup in "administrative events", but there was no schedule that started it at 2:30am. I don't think we need to go too much further to figure this out, I think you hit the nail on the head with the storage pool going past the high migration threshold. They run a huge DB2 backup on the weekend which I"m sure may have caused that. thanks for the help (also thanks to Jim Sporer) Tommy - Original Message - From: "Andrew Raibeck" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, March 10, 2003 1:01 PM Subject: Re: Admin schedules > Can you provide a little more information about the problem? For example, > what makes you say that the migration started as a result of the Admin > schedule? Does the activity log actually show the schedule being run? What > does the definition of this schedule look like (output from Q SCH F=D for > this schedule)? I would think it more likely that backups just filled the > storage pool past the high migration theshold, so migration started on its > own. > > Regards, > > Andy > > Andy Raibeck > IBM Software Group > Tivoli Storage Manager Client Development > Internal Notes e-mail: Andrew Raibeck/Tucson/[EMAIL PROTECTED] > Internet e-mail: [EMAIL PROTECTED] (change eye to i to reply) > > The only dumb question is the one that goes unasked. > The command line is your friend. > "Good enough" is the enemy of excellence. > > > > > Tommy Templeton <[EMAIL PROTECTED]> > Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > 03/10/2003 11:23 > Please respond to "ADSM: Dist Stor Manager" > > > To: [EMAIL PROTECTED] > cc: > Subject:Admin schedules > > > > Environment: > Server: RS/6000-AIX5.1 TSM V4.2.1.9 > Client: NT4-Service pack 6, > Win2k-SP1, TSM V4.2.1.9 > Novell - Netware 6 TSM V5.1.5.0 > SP2-AIX5.1 TSM V4.2.1.9 > > > Hi *SM'ers , > > I have an admin schedule setup that does my disk migration to primary tape > at 8:15am every day. > I had a weird problem with that schedule starting up at 2:35am in the > middle of backups. Has anyone else had unexpected results with the TSM > admin schedules before? It usually runs fine, > > Thanks, > > > Tommy Templeton
Admin schedules
Environment: Server: RS/6000-AIX5.1 TSM V4.2.1.9 Client: NT4-Service pack 6, Win2k-SP1, TSM V4.2.1.9 Novell - Netware 6 TSM V5.1.5.0 SP2-AIX5.1 TSM V4.2.1.9 Hi *SM'ers , I have an admin schedule setup that does my disk migration to primary tape at 8:15am every day. I had a weird problem with that schedule starting up at 2:35am in the middle of backups. Has anyone else had unexpected results with the TSM admin schedules before? It usually runs fine, Thanks, Tommy Templeton
Re: mtlib command
That works well - thanks. Tommy Templeton - Original Message - From: "Conko, Steven" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, March 06, 2003 10:53 AM Subject: Re: mtlib command > i believe we had the same problem. try this: > > mtlib -l /dev/lmcp0 -vC -Vvolser -tFFFB > > > steve conko > -Original Message- > From: Tommy Templeton [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 06, 2003 11:39 AM > To: [EMAIL PROTECTED] > Subject: mtlib command > > > Does anyone know the mtlib command to clear erroneous volumes from > inventory. These volumes were in the library but have been checked out. > We use a 3494 library. > > thanks > > Tommy Templeton
mtlib command
Does anyone know the mtlib command to clear erroneous volumes from inventory. These volumes were in the library but have been checked out. We use a 3494 library. thanks Tommy Templeton
Re: Problem while using "move drmedia"
ed into library 3494VTS. 02/28/03 13:26:33 ANR8430I Volume AIX096 has been checked into library 3494VTS. 02/28/03 13:26:34 ANR8443E CHECKIN LIBVOLUME: Volume AIX099 in library 3494VTS cannot be assigned a status of SCRATCH. 02/28/03 13:26:34 ANR8430I Volume AIX100 has been checked into library 3494VTS. 02/28/03 13:26:34 ANR8443E CHECKIN LIBVOLUME: Volume AIX050 in library 3494VTS cannot be assigned a status of SCRATCH. 02/28/03 13:26:34 ANR8430I Volume AIX121 has been checked into library 3494VTS. 02/28/03 13:26:34 ANR8430I Volume AIX128 has been checked into library 3494VTS. 02/28/03 13:26:35 ANR8430I Volume AIX147 has been checked into library 3494VTS. 02/28/03 13:26:35 ANR8430I Volume AIX132 has been checked into library 3494VTS. 02/28/03 13:26:35 ANR8430I Volume AIX022 has been checked into library 3494VTS. 02/28/03 13:26:35 ANR8431I CHECKIN LIBVOLUME process completed for library 3494VTS; 22 volume(s) found. 02/28/03 13:26:35 ANR0985I Process 143 for CHECKIN LIBVOLUME running in the BACKGROUND completed with completion state SUCCESS at 13:26:35. - Original Message - From: "Orville Lantto" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, February 28, 2003 11:47 AM Subject: Re: Problem while using "move drmedia" > This may be a manifestation of the following APAR. This was repaired in > 4.2.1.13 > > <@> > IC33056 TSM 4.2.1 3494 CATEGORIES SCRATCH PRIVATE INSERT > > When multiple TSM V4.2.1 Servers are using the same > partitioned 3494 Tape Library it is possible for a volume to > get checked into the wrong server. As of 4.2.1 and higher the > TSM server will not check what category a volume belongs to > during a "checkin libvol xx search=no" command. Therefore > it is possible for a volume belonging to one TSM server to get > checked into a different TSM server. The Server will change > the volume category to reflect the category assigned to that > particular status for that specific TSM server. This issue > will only occur when a manual checkin is done and the > "search=no" parameter is used. > This particular issue was found when a customer setup multiple > instances of the TSM Server on the same Unix machine but can > also occur when two separate machines are used to access a > partitioned 3494 Tape Library. > Output from a PVR trace will show TSM recognizing that the > volume being checked in has a different category than what > has been defined for that server instance, for example;362 > TSM changing the tape category to cat=65280 (FF00) (the insert > category) then changing the category to the appropriate status > for that server, for example; 372 for a scratch tape. > > Orville L. Lantto > Datatrend Technologies, Inc. (http://www.datatrend.com) > IBM Premier Business Partner > 121 Cheshire Lane, Suite 700 > Minnetonka, MN 55305 > Email: [EMAIL PROTECTED] > > CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is > for the sole use of the intended recipient(s) and may contain confidential > and privileged information. Any unauthorized review, use, disclosure or > distribution is prohibited. If you are not the intended recipient, please > contact the sender by reply e-mail and destroy all copies of the original > message. > > > > > Tommy Templeton <[EMAIL PROTECTED]> > Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > 02/27/2003 09:57 AM > Please respond to "ADSM: Dist Stor Manager" > > > To: [EMAIL PROTECTED] > cc: > Subject:Problem while using "move drmedia" > > > Hi *SM'ers > > This morning I was running this script: > > move drmedia * wherestate=vaultretrieve copystgpool=offsitepool1 > source=dbsnapshot > checkin libv 3494vts search=yes status=scratch devt=3590 checkl=no > query actlog search="MOVE DRMEDIA" > > I got some unexpected results. Not only did I get the tapes that I was > expecting but I got several tapes that I had on "could not locate" list of > tapes that seemed to be missing from the vts. What was stranger is that I > checked in about 10 volumes that don't even belong in my library. I share > the VTS "robitics unit" with another state agency but my 3494 library is > not shared. Has anyone had any problems like this? > > Environment: > Server: RS/6000-AIX5.1 TSM V4.2.1.9 > Client: NT4-SP6, > Win2k-SP1, > SP2-AIX5.1 TSM V4.2.1.9 > Environment: > Server: RS/6000-AIX5.1 TSM V4.2.1.9 > Client: NT4-SP6, Win2k-SP1,SP2-AIX5.1 TSM V4.2.1.9 > > > thanks, > > > Tommy Templeton > Senior System Administrator > DFA-MMRS > 601-359-3106 > e-mail - [EMAIL PROTECTED]
Re: StorServer
Thanks Paul. We were impressed with the interface. I think it would help us out overall here. - Original Message - From: "Paul Roth" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, February 27, 2003 1:38 PM Subject: Re: StorServer > We have been using this product for two years- like for our admin assistant - makes moving tapes easy. > > Paul Roth > Ohio State University Medical Center > Sr. Systems Developer/Engineer > [EMAIL PROTECTED] > 614-293-6224
StorServer
We just had a webcast with StorServer. I was wondering if anyone on the list has used this product or had any opinions on it? We liked it and thought it would be a good TSM management tool to have. Tommy Templeton Senior System Administrator DFA-MMRS 601-359-3106 e-mail - [EMAIL PROTECTED]
Problem while using "move drmedia"
Hi *SM'ers This morning I was running this script: move drmedia * wherestate=vaultretrieve copystgpool=offsitepool1 source=dbsnapshot checkin libv 3494vts search=yes status=scratch devt=3590 checkl=no query actlog search="MOVE DRMEDIA" I got some unexpected results. Not only did I get the tapes that I was expecting but I got several tapes that I had on "could not locate" list of tapes that seemed to be missing from the vts. What was stranger is that I checked in about 10 volumes that don't even belong in my library. I share the VTS "robitics unit" with another state agency but my 3494 library is not shared. Has anyone had any problems like this? Environment: Server: RS/6000-AIX5.1 TSM V4.2.1.9 Client: NT4-SP6, Win2k-SP1, SP2-AIX5.1 TSM V4.2.1.9 Environment: Server: RS/6000-AIX5.1 TSM V4.2.1.9 Client: NT4-SP6, Win2k-SP1,SP2-AIX5.1 TSM V4.2.1.9 thanks, Tommy Templeton Senior System Administrator DFA-MMRS 601-359-3106 e-mail - [EMAIL PROTECTED]
Re: Checkin multiple tapes to 3494 library
The tapes are pre-labeled and initialized. This is my response when I do a "q libr". According to the output below, I don't think the library is shared. We do share a robotics unit with another agency but they have their own library. Library Name: 3494VTS Library Type: 349X Device: /dev/lmcp0 Private Category: 300 Scratch Category: 301 External Manager: Shared: No LanFree: ObeyMountRetention: - Original Message - From: "Allen Barth" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, February 25, 2003 4:19 PM Subject: Re: Checkin multiple tapes to 3494 library > You got several answers, but I got questions for you. > > 1. Is the 3494 shared? > 2. Do you know if the tapes are initialized? > > If the 3494 is shared, you can't just do a search=yes because you may very > well get tapes that *shouldn't* belong to ITSM > If the tapes aren't initialized then you can't just do a checkin. You'll > need to do a DSMLABEL or LABEL LIBV > > > > > > Tommy Templeton <[EMAIL PROTECTED]> > Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > 02/25/03 01:30 PM > Please respond to "ADSM: Dist Stor Manager" > > > To: [EMAIL PROTECTED] > cc: > Subject: Checkin multiple tapes to 3494 library > > > Hi *SM'ers > > Is there a way to check in multiple new volumes (with barcodes) to a 3494 > library as scratch? > > Tommy Templeton > Senior System Administrator > DFA-MMRS > 601-359-3106 > e-mail - [EMAIL PROTECTED]
Checkin multiple tapes to 3494 library
Hi *SM'ers Is there a way to check in multiple new volumes (with barcodes) to a 3494 library as scratch? Tommy Templeton Senior System Administrator DFA-MMRS 601-359-3106 e-mail - [EMAIL PROTECTED]
Re: checkin command
I forgot to include my system information: Environment: Server: RS/6000-AIX5.1 TSM V4.2.1.9 Client: NT4-SP6, Win2k-SP1, SP2-AIX5.1 TSM V4.2.1.9 - Original Message - From: "Tommy Templeton" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, February 24, 2003 4:42 PM Subject: Re: checkin command > We have 3590e tapes and I'm trying to incorporate this command into those > server command scripts on the TSM server. > I'm trying to put together an offsite backup process. We've been > doing our offsite process all wrong and I'm trying to correct it. I guess I > need to put another script in to do a > dbsnapshot. (Any offsite help would also be appreciated. I seem to be > having difficulty in setting all of this up). > > > I put together this scipt to move tapes offsite: > > move drmedia * source=dbsnapshot tolocation=vault remove=yes wait=yes > query actlog search="MOVE DRMEDIA" > > I have this script to move tapes back onsite. > > move drmedia * wherestate=vaultretrieve copystgpool=offsitepool1 > source=dnsnapshot > checkin libv libname search=yes status=scratch devt=3590 checkl=no > query actlog search="MOVE DRMEDIA" > > > > > > > > - Original Message - > From: "Kason Leung" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, February 24, 2003 4:15 PM > Subject: Re: checkin command > > > > It looks like you're trying to check in a single volume. In that case, > > you'll need to specify the devtype parameter in your checkin command. > > > > This is what we do to checkin a single tape: checkin libvol 3494A > > devtype=3590 status=scratch > > > > I'm assuming your 3494 has 3590 drives in it. > > > > Kason Leung > > Systems Programmer II > > University of California > > Office of the President > > 510-987-0345 > > E-mail: [EMAIL PROTECTED] > > > > > > > > At 04:01 PM 2/24/2003 -0600, Tommy Templeton wrote: > > >Does this command work in a 3494 environment? Does there have to be any > > >conditions to use it. > > >The last time I tried to run it, I didn't have very good success. I could > > >have been doing something wrong. > > > > > >checkin libvol 3494vts &vol status=scratch > > > > > >Tommy Templeton > > >Senior System Administrator > > >DFA-MMRS > > >601-359-3106 > > >e-mail - [EMAIL PROTECTED]
Re: checkin command
We have 3590e tapes and I'm trying to incorporate this command into those server command scripts on the TSM server. I'm trying to put together an offsite backup process. We've been doing our offsite process all wrong and I'm trying to correct it. I guess I need to put another script in to do a dbsnapshot. (Any offsite help would also be appreciated. I seem to be having difficulty in setting all of this up). I put together this scipt to move tapes offsite: move drmedia * source=dbsnapshot tolocation=vault remove=yes wait=yes query actlog search="MOVE DRMEDIA" I have this script to move tapes back onsite. move drmedia * wherestate=vaultretrieve copystgpool=offsitepool1 source=dnsnapshot checkin libv libname search=yes status=scratch devt=3590 checkl=no query actlog search="MOVE DRMEDIA" - Original Message - From: "Kason Leung" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, February 24, 2003 4:15 PM Subject: Re: checkin command > It looks like you're trying to check in a single volume. In that case, > you'll need to specify the devtype parameter in your checkin command. > > This is what we do to checkin a single tape: checkin libvol 3494A > devtype=3590 status=scratch > > I'm assuming your 3494 has 3590 drives in it. > > Kason Leung > Systems Programmer II > University of California > Office of the President > 510-987-0345 > E-mail: [EMAIL PROTECTED] > > > > At 04:01 PM 2/24/2003 -0600, Tommy Templeton wrote: > >Does this command work in a 3494 environment? Does there have to be any > >conditions to use it. > >The last time I tried to run it, I didn't have very good success. I could > >have been doing something wrong. > > > >checkin libvol 3494vts &vol status=scratch > > > >Tommy Templeton > >Senior System Administrator > >DFA-MMRS > >601-359-3106 > >e-mail - [EMAIL PROTECTED]
checkin command
Does this command work in a 3494 environment? Does there have to be any conditions to use it. The last time I tried to run it, I didn't have very good success. I could have been doing something wrong. checkin libvol 3494vts &vol status=scratch Tommy Templeton Senior System Administrator DFA-MMRS 601-359-3106 e-mail - [EMAIL PROTECTED]
Re: Order of daily administrative events
Thats what I thought too. We are doing it that way now also. Thanks. - Original Message - From: "Lambelet,Rene,VEVEY,GL-CSC" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, February 21, 2003 8:55 AM Subject: Re: Order of daily administrative events > well, i would backup storage before migrating it, will spare many tape > mounts ! > > > > -Original Message- > From: Tommy Templeton [mailto:[EMAIL PROTECTED]] > Sent: Friday,21. February 2003 15:52 > To: [EMAIL PROTECTED] > Subject: Re: Order of daily administrative events > > > Thanks. I've gotten lots of good responses to this question. TSM support > told me the order they suggest is something like: > > Expire > Reclaim > Migrate > Backup Storage > Backup Database > Set Migrate back to high > Set Reclaim back to high > Move DRM > > (This is with backups being run at night) > > Most of the order of events that I've seen (including mine) are not quite > set up the way TSM support suggests. I wonder if there is an optimum way to > do this or if it depends on the needs of your shop? > > By the way, I like your idea about Expiration running at night. I hadn't > thought of that. > > Tommy Templeton > Senior System Administrator > DFA-MMRS > 601-359-3106 > e-mail - [EMAIL PROTECTED] > > - Original Message - > From: "Paul Ripke" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, February 20, 2003 5:07 PM > Subject: Re: Order of daily administrative events > > > > My 5 AUS cents: > > > > - backup diskpool -> offsite pool > > - migrate diskpool -> primary tape > > - backup primary tape -> offsite > > - backup db > > - eject drm > > - run reclamaitions > > > > Expiration runs during a quite period over night. > > > > Cheers, > > -- > > Paul Ripke > > Unix/OpenVMS/TSM/DBA > > 101 reasons why you can't find your Sysadmin: > > 68: It's 9AM. He/She is not working that late. > > -- Koos van den Hout
Re: Order of daily administrative events
Thanks. I've gotten lots of good responses to this question. TSM support told me the order they suggest is something like: Expire Reclaim Migrate Backup Storage Backup Database Set Migrate back to high Set Reclaim back to high Move DRM (This is with backups being run at night) Most of the order of events that I've seen (including mine) are not quite set up the way TSM support suggests. I wonder if there is an optimum way to do this or if it depends on the needs of your shop? By the way, I like your idea about Expiration running at night. I hadn't thought of that. Tommy Templeton Senior System Administrator DFA-MMRS 601-359-3106 e-mail - [EMAIL PROTECTED] - Original Message - From: "Paul Ripke" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, February 20, 2003 5:07 PM Subject: Re: Order of daily administrative events > My 5 AUS cents: > > - backup diskpool -> offsite pool > - migrate diskpool -> primary tape > - backup primary tape -> offsite > - backup db > - eject drm > - run reclamaitions > > Expiration runs during a quite period over night. > > Cheers, > -- > Paul Ripke > Unix/OpenVMS/TSM/DBA > 101 reasons why you can't find your Sysadmin: > 68: It's 9AM. He/She is not working that late. > -- Koos van den Hout
Order of daily administrative events
I was just wondering what order that most TSM users have their daily processes running (IE: Migration, Expiration, Reclaim etc). It seems that those process times were set up wrong when our TSM server was first installed. Our process schedule looks this way right now. I know its way off base from what it should be. Any suggestions? I know I need to put EXPIRATION first. thanks, Tommy Templeton Senior System Administrator DFA-MMRS 601-359-3106 e-mail - [EMAIL PROTECTED] Scheduled Start Actual Start Schedule Name Status - - 02/19/03 06:00:0002/19/03 06:00:16BACKUPSTG_D- Completed Backup disk storagepool ISK 02/19/03 06:15:0002/19/03 06:15:17BACKUPSTG_T- Completed Backup tape storagepool 02/19/03 07:30:0002/19/03 07:30:18BACKUPSTG_O- Failed Backup tape offsitepool FFSITE 02/19/03 09:00:0002/19/03 09:00:19RESET_MIGR_- Completed Reset threshold for migrate to tape pool low LOW 02/19/03 11:00:0002/19/03 11:00:20RESET_RECLA- Completed Reset threshold for reclamation of offsitepool1 low IM_OFFSITE- _LOW 02/19/03 13:00:0002/19/03 13:03:50DBBACKUP_FULL Completed TSM database backup 02/18/03 14:00:0002/18/03 14:00:11EXPIRE_INVE- Completed Expire inventory NTORY 02/19/03 14:00:0002/19/03 14:00:21RESET_MIGR_- Completed Reset threshold for migrate to tape pool high HIGH 02/19/03 14:00:0002/19/03 14:00:21RESET_RECLA- Completed Reset threshold for reclamation of tapepool low IM_LOW 02/19/03 17:00:0002/19/03 17:00:21DELETE_VOL_- Completed Delete volume history file HIST 02/19/03 17:00:0002/19/03 17:00:21DEL_DBVOL_H- Completed Delete database volume history IST 02/19/03 17:15:0002/19/03 17:15:21DEL_DBSNAP_- Completed delete dbsnapshot volume history HIST 02/19/03 18:00:0002/19/03 18:00:22RESET_RECLA- Completed Reset threshold for reclamation of tapepool high IM_HIGH 02/19/03 18:30:0002/19/03 18:30:22RESET_RECL_- Completed Reset threshold for reclaim of copy pool high COPY_HIGH 02/19/03 19:00:0002/19/03 19:00:22RESET_RECLA- Completed Reset threshold for reclamation of offsitepool1high IM_OFFSITE- _HIGH
Re: Order of daily administrative events
Thanks. Maybe I can get my system streamlined and get my offsite backup flow going, I think I am having a problem with optimizing my resources. Luckily I have this list to bounce ideas off of because I'm the administrator here and there aren't any other folks onsite that I can share ideas with and get info from. I can get more answers here sometimes than I can with TSM support. I'm glad I found this list. Tommy Templeton Senior System Administrator DFA-MMRS 601-359-3106 e-mail - [EMAIL PROTECTED] - Original Message - From: "Lawrence Clark" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, February 20, 2003 11:26 AM Subject: Re: Order of daily administrative events > Yours has a bit more detail. We do DR plan and backup of config files > and DB at thesame time, back them up to 8MM outside the TSM environment, > and take that 8MM offsite, leaving a copy of the DB backup on disk. > > Backups > > creation of copypool volumes > > Migration from disk to cartridge > > DB backup and config files > > Checkout offsite vols..(no longer done because primary > storage pool tape library and copypool tape library are in different > locations. So cartridges no longer handled manually > > Expiration (which triggers reclamation) > > > >>> [EMAIL PROTECTED] 02/20/03 11:50AM >>> > Ours is slightly different, > > set migration thresholds to just less than the size of a tape, > so > migration will go on during backups. > > Backups (we have enough disk to hold 3-4 days of incrementals, > so we > do cache files) > creation of copypool volumes (from disk pools first, then tape > pool) > backup devconfig and volhist > purge volhist of old stuff > db backup > make DR plan file > eject copypool tape volumes and db backup, put dr plan on > offsite > media to go with the db backup. > Expiration (which triggers reclamation) > > from time to time, I have also done a 'backup diskpool > copypool > wait=y', and 'backup tapepool copypool' > before backups to make sure everything that can be is already > on a > copypool tape. the copypool tape > is appended to at the end of the nightly process. > > my morning script follow: > > /* Daily Backup Activities */ > /* executed by the dailybackup command schedule */ > backup stg diskdata copypool wait=y > backup stg diskdirs copypool wait=y > backup stg tapedata copypool wait=y > move drmedia * wherest=courier wait=y > backup devconfig > backup volhist > delete volhist type=all todate=today-62 > delete volhist type=db todate=today-2 > /* backup db, scratch=yes, type=full, wait=yes */ > backup db dev=ltoclass1 scratch=y type=full wait=y > prepare wait=yes > move drmedia * wherestate=mo rem=bulk wait=yes > update stg diskdata hi=0 lo=0 > update stg diskdirs hi=0 lo=0 > expire inventory wait=yes > update stg diskdata hi=20 lo=3 cache=y > update stg diskdirs hi=90 lo=5 cache=y > move drmedia * wherestate=courierr wait=yes > move drmedia * wherestate=mo rem=bulk wait=yes > move drmedia * wherestate=notmountable - > wait=yes rem=bulk > /* */ > the move drmedia is a figment of having DRM. > If someone has a better way, please let me know. ... Always trolling > for > constructive criticism. > > > -Original Message- > > From: Lawrence Clark [SMTP:[EMAIL PROTECTED]] > > Sent: Thursday, February 20, 2003 10:36 AM > > To: [EMAIL PROTECTED] > > Subject: Re: Order of daily administrative events > > > > Backups > > creation of copypool volumes > > Migration from disk to cartridge > > DB backup > > Expiration (which triggers reclamation) > > > > >>> [EMAIL PROTECTED] 02/20/03 11:28AM >>> > > I was just wondering what order that most TSM users have their daily > > processes running (IE: Migration, Expiration, Reclaim etc). > > It seems that those process times were set up wrong when our TSM > server > > was first installed. > > Our process schedule looks this way right now. I know its way off > base > > from what it should be. > > Any suggestions? I know I need to put EXPIRATION first. > > > > thanks, > > > > Tommy Templeton > > Senior System Administrator > > DFA-MMRS > > 601-359-3106 > > e-mail - [EMAIL PROTECTED] > > > > Scheduled Start Actual
Re: Order of daily administrative events
Thanks. That sounds like a good plan. Thats interesting about using the disk for quicker restores during the day. I guess I should run some kind of weekend reclaim plan too. I can't seem to keep the other pools from eating all of my scratch tapes. Do you run a script on the weekend that drops your reclaim down to 10 or something like that? - Original Message - From: "William Rosette" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, February 20, 2003 10:53 AM Subject: Re: Order of daily administrative events > We: > 1. backup up Disk and Tape onsite, > 2. then Database backup, > 3. then DRM (Disaster Recovery Media) plan and DR files (double) and also > DR cleanup (eg. delete volhistory and others), > 4. then Expiration, > 5. then Migration (at end of day to use disk for quicker restores), > 6. and on weekends we run Reclamation all weekend. > So far has been working good. Our DRM plan gets done around 12:00 noon > when the whole process (in a script) starts around 5:20, trying to get to > start earlier so we can finish earlier to get DRM plan on the mksysb tape > out door in morning for a true DR. > > Thank You, > Bill Rosette > Data Center/IS/Papa Johns International > WWJD > > > > Lawrence Clark > <[EMAIL PROTECTED]To: [EMAIL PROTECTED] > TATE.NY.US> cc: > Sent by: "ADSM: Dist Subject: Re: Order of daily administrative events > Stor Manager" > <[EMAIL PROTECTED]> > > > 02/20/2003 11:35 AM > Please respond to > "ADSM: Dist Stor > Manager" > > > > > > > Backups > creation of copypool volumes > Migration from disk to cartridge > DB backup > Expiration (which triggers reclamation) > > >>> [EMAIL PROTECTED] 02/20/03 11:28AM >>> > I was just wondering what order that most TSM users have their daily > processes running (IE: Migration, Expiration, Reclaim etc). > It seems that those process times were set up wrong when our TSM server > was first installed. > Our process schedule looks this way right now. I know its way off base > from what it should be. > Any suggestions? I know I need to put EXPIRATION first. > > thanks, > > Tommy Templeton > Senior System Administrator > DFA-MMRS > 601-359-3106 > e-mail - [EMAIL PROTECTED] > > Scheduled Start Actual Start Schedule Name > Status > - > - > 02/19/03 06:00:0002/19/03 06:00:16BACKUPSTG_D- > CompletedBackup disk storagepool >ISK > > 02/19/03 06:15:0002/19/03 06:15:17BACKUPSTG_T- > Completed Backup tape storagepool > 02/19/03 07:30:0002/19/03 07:30:18BACKUPSTG_O- > Failed Backup tape offsitepool FFSITE > 02/19/03 09:00:0002/19/03 09:00:19RESET_MIGR_- > Completed Reset threshold for migrate to tape pool low >LOW > > 02/19/03 11:00:0002/19/03 11:00:20RESET_RECLA- > Completed Reset threshold for reclamation of offsitepool1 low > >IM_OFFSITE- > >_LOW > > 02/19/03 13:00:0002/19/03 13:03:50DBBACKUP_FULL > CompletedTSM database backup > 02/18/03 14:00:0002/18/03 14:00:11EXPIRE_INVE- > Completed Expire inventory >NTORY > > > 02/19/03 14:00:0002/19/03 14:00:21RESET_MIGR_- > Completed Reset threshold for migrate to tape pool high >HIGH > > 02/19/03 14:00:0002/19/03 14:00:21RESET_RECLA- > Completed Reset threshold for reclamation of tapepool low >IM_LOW > > 02/19/03 17:00:0002/19/03 17:00:21DELETE_VOL_- > CompletedDelete volume history file >HIST > > 02/19/03 17:00:0002/19/03 17:00:21DEL_DBVOL_H- > CompletedDelete database volume history >IST > > 02/19/03 17:15:0002/19/03 17:15:21DEL_DBSNAP_- > Completeddelete dbsnapshot volum
Re: Diskpool error
Mark, Thanks for the reply. I was talking with the DBA for the client in question. It looks like he requires 130gb and the diskpool's estimated capacity in MB's is 107668.0 It sounds like we are going to have to buy more disk. Tommy - Original Message - From: "Darby, Mark" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, February 10, 2003 5:53 PM Subject: Re: Diskpool error > Tommy, the following must be true for the situation in question: > 1. the disk storage pool in question has CACHE turned on > 2. COMPRESSION=YES is in effect for the client in question > 3. COMPRESSALWAYS=NO is NOT in effect for the client in question > 4. the file being backed up at the time of the error was growing as a result > of compression > > The reason it is happening is because the above are all in effect and is > explained by the following partial description of the backup process: > 1. when a file is to be backed up by the client, it provides the server with > an estimate of the amount of space required to store the file > 2. when, because of compression, a file grows during the backup, the client > revises its estimate with the server and, when COMPRESSALWAYS=YES (the > default) is in effect, continues sending the file, still compressing it > 3. when CACHE is "turned on" for the storage pool in question, the server > does not check the "CACHEd file space" for room based on the revised > estimate (even though it does so at the beginning - in step 1 above) > 4. if the server does not find "actual free space" (not including cached > file space that COULD be freed to make room to store the file), the server > responds as indicated in your problem situation. > > There are lots of ways to solve this problem, including using > COMPRESSALWAYS=NO or turning off COMPRESSION altogether (e.g., > COMPRESSION=NO), or (just for the file in question) using (if supported by > the client platform/level) exclude.compression. > > You can also turn off caching for the storage pool in question - does it > actually provide you any real benefit, anyway? > > Regards, > Mark > > -Original Message- > From: Tommy Templeton > To: [EMAIL PROTECTED] > Sent: 2/10/03 5:38 PM > Subject: Diskpool error > > I got this error during one of my weekend backups. Is anyone else > familiar with diskpool errors like this? Thanks. > > 02/09/03 03:44:25 ANR0534W Transaction failed for session 184 for node > > SP2MN5F0 (DB2/6000) - size estimate exceeded and server > > is unable to obtain additional space in storage pool > > DISKPOOL. > > > > Tommy Templeton > Senior System Administrator > DFA-MMRS > 601-359-3106 > e-mail - [EMAIL PROTECTED]
Diskpool error
I got this error during one of my weekend backups. Is anyone else familiar with diskpool errors like this? Thanks. 02/09/03 03:44:25 ANR0534W Transaction failed for session 184 for node SP2MN5F0 (DB2/6000) - size estimate exceeded and server is unable to obtain additional space in storage pool DISKPOOL. Tommy Templeton Senior System Administrator DFA-MMRS 601-359-3106 e-mail - [EMAIL PROTECTED]
Re: TSM 5.1.5 B/A Client and Netware 6
We recently migrated to Netware 6 our only server running netware. We've not been able to backup that server for about a week now. I tried to reinstall the 5.1.5 .0 B/A client again and I am still getting these errors: 02/07/03 16:04:30 ANRD smnode.c(6243): ThreadId<27> Error receiving EventLog Verb - invalid data type, 29793, received for event number 4959 from node (NetWare)MMRSSERV. 02/07/03 16:04:30 ANRD smnode.c(6243): ThreadId<27> Error receiving EventLog Verb - invalid data type, 29793, received for event number 4961 from node (NetWare)MMRSSERV. (BTW - we are running TSM server version 4.2.1.9 on an RS 6000) . We are trying to get the cd for version 5 (base level) but we are having a few challanges with vendors etc. Here is a correspondence with TSM support that I recently had. Tommy, I did some research and think I found the problem. The resolution will require an upgrade of the TSM server to 5.1.5. This problem should be resolved in APAR IC34288. Here is excerpt from the APAR. TSM server 5.1.0.2 has shown to core dump (abend) when passed an invalid data type 21300 as and EventLog Verb from the client. . Traceback: . 0x000100A4DA44 pkFreeTracked 0x000100765F94 SmDoEventLog 0x000100761F9C SmNodeSession 0x0001007ACA90 SmSchedSession 0x00010073FE20 HandleNodeSession 0x0001007401CC DoNodeSched 0x00010073D1B4 smExecuteSession 0x00010007C194 SessionThread 0x00010006C2FC StartThread 0x7EB1F8A0 *UNKNOWN* 0x00010006C1DC StartThread . Actlog: . ANRD smnode.c(6566): ThreadId<66> Error receiving EventLog Verb - invalid data type, 21300, received for event number 4987 from node (WinNT) . Keywords: Crash abort abnormal termination terminate dump LOCAL FIX: None. However the invalid EventLog Verb being sent has been shown in some cases to be the result of an improperly installed windows client. If the windows client has been upgraded from a prior major release (such as 4.1 or 4.2) to a current release but the system has not been rebooted following the upgrade the invalid data type may be the result. A reboot of the client system will sometimes clear this problem. What level of TSM server do you have installed? I would upgrade to 5.1.5.0 if your version of TSM is not at this level or higher. Steve Runyon , Tivoli Privacy Manager & Tivoli Certified Firewall L2 Software Engineer (919) 254-8751 - Bld660/EE105 [EMAIL PROTECTED] - - Original Message - From: "Kamp, Bruce" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, February 07, 2003 12:51 PM Subject: Re: TSM 5.1.5 B/A Client and Netware 6 > I have 3 Netware 6 servers. > 1 running 5.1.0.0 > 1 running 5.1.5.1 > 1 running 5.1.5.6 > > I haven't noticed any problems... > The 5.1.5.6 server is backing up slow but I think that is because it is out > first Netware server on gigabit & haven't completely tuned the NIC & > network > > -- > Bruce Kamp > Midrange Systems Analyst II > Memorial Healthcare System > E: [EMAIL PROTECTED] > P: (954) 987-2020 x4597 > F: (954) 985-1404 > --- > > > -Original Message- > From: Tommy Templeton [mailto:[EMAIL PROTECTED]] > Sent: Friday, February 07, 2003 11:20 AM > To: [EMAIL PROTECTED] > Subject: TSM 5.1.5 B/A Client and Netware 6 > > > Hi TSMers > > Has anyone had any challenges with TSM 5.1.5 on a client running Netware 6? > > thanks, > > Tommy Templeton > Senior System Administrator > DFA-MMRS > 601-359-3106 > e-mail - [EMAIL PROTECTED]
TSM 5.1.5 B/A Client and Netware 6
Hi TSMers Has anyone had any challenges with TSM 5.1.5 on a client running Netware 6? thanks, Tommy Templeton Senior System Administrator DFA-MMRS 601-359-3106 e-mail - [EMAIL PROTECTED]
TSM copygroup settings
Our organization would like to be able to have 30 days of backups to restore to on production servers. I had my "versions data exists" at 30 but I cut it back down due to tape storage restraints. I have a DBA that says he needs to have "Versions data deleted" at 10 due to considerations he has with his AIX-SP2 system. I have a request to up my settings back to 30 but I was wondering if there is a way I can optimize these settings and still get management what they want. I have my copygroup setup this way currently: Operation Results PolicyPolicyMgmt Copy Versions Versions Retain Retain DomainSet Name Class Group Data DataExtraOnly NameName NameExists Deleted Versions Version - - - - --- MMRS_DB- ACTIVEMMRS_DB- STANDARD20 10 25 50 2_PD2_DB_MC MMRS_DB- ACTIVEMMRS_DB- STANDARD20 10 25 50 2_PD2_FS_MC MMRS_DB- MMRS_DB- MMRS_DB- STANDARD20 10 25 50 2_PD 2_PS 2_DB_MC MMRS_DB- MMRS_DB- MMRS_DB- STANDARD20 10 25 50 2_PD 2_PS 2_FS_MC MMRS_ME- ACTIVEMMRS_ME- STANDARD20 10 25 50 RLIN_PD RLIN_MC MMRS_ME- MMRS_ME- MMRS_ME- STANDARD20 10 25 50 RLIN_PD RLIN_PS RLIN_MC MMRS_NE- ACTIVEMMRS_NE- STANDARD153 25 50 TWORK_- TWORK_MC NONPRO- D_PD MMRS_NE- MMRS_NE- MMRS_NE- STANDARD153 25 50 TWORK_- TWORK_PS TWORK_MC NONPRO- D_PD MMRS_NE- ACTIVEMMRS_NE- STANDARD203 25 50 TWORK_PDTWORK_MC MMRS_NE- MMRS_NE- MMRS_NE- STANDARD203 25 50 Tommy TempletonSenior System AdministratorDFA-MMRS601-359-3106e-mail - [EMAIL PROTECTED]
TSM having trouble backing up Netware 6 Client
Environment: Server: RS/6000-AIX5.1 TSM V4.2.1.9 Client: NT4-SP6, Win2k-SP1, IBM/SP2-AIX5.1TSM V4.2.1.9 Netware 6 client with TSM B/A Client V 5.1.5.0 I was wondering if anyone had any challenges with TSM backups not working after migrating a client to Netware 6. This is what is happening here. We just upgraded to Netware 6 on our Netware client. After the migration the scheduled backup job was not able to talk to the TSM server and we got this message: 01/29/03 01:09:37 ANR8213W Session open with (10.###.##.##) timed out. 01/29/03 01:09:37 ANR2716E Schedule prompter was not able to contact client MMRSSERV using type 1 (10.###.##.## ###). TSM support then told us to upgrade our TSM 3.7 client on the Netware Client to TSM V 5.1.5.0 . We did this and then started getting this message: 02/01/03 08:50:53 ANRD smnode.c(6243): ThreadId<23> Error receiving EventLog Verb - invalid data type, 21300, received for event number 4005 from node (NetWare)MMRSSERV. ** TSM support says we need to upgrade our TSM Server version to 5.1.5 Our software rep says: Our current version of NSM is 4.2 (server version). This is as far as we can go with NSM. We need to migrate from NSM to TSM server software. This is provided through "passport advantage" which is no longer through them. He says we need to contact our passport advantage vendor and request the necessary software for migration. After all of this, will our backups work for netware?????? Tommy Templeton Senior System Administrator DFA-MMRS 601-359-3106 e-mail - [EMAIL PROTECTED]
TSM offsite backups
Hi, I need to start sending tapes offsite but I want to keep 2 sets of tapes onsite and have another pool for offsite tapes. I have the available tapes to use for the offsite pool. I have DRM installed. Our TSM server is running Version 4.2 Level 1.9 , TSM B/A client is 4.2 on AIX 4.3.3. I just need some tips on how to get this going. thanks, Tommy Templeton Senior System Administrator DFA-MMRS 601-359-3106 e-mail - [EMAIL PROTECTED]
