Re: vaulting primary storage pool volumes
Hmm, In the 5.2.2 Administrators Reference the "Set DRMCOPYSTGPOOL" definition makes mention that the storage pools listed there, which by default is all copy storage pools, are considered for the move drmedia command. However, if you review the definition for "Set DRMPRIMSTGPOOL" you will see that notes about the move drmedia command have been left out. In addition if you check the 5.2.2 Administrators Guide you will see that the default at installation is "All primary storage pools". You seem pretty sure that using the Set DRMPRIMSTGPOOL command will somehow eject primary tapes with the move drmedia command. If this were true then wouldn't everyone's primary pool tapes be ejecting being that all pools are included by default? I admit I have not used this option either maybe a doc APAR should be open if it setting the option does affect move dremedia. tsmadmin account for Excaliber Business Solutions <[EMAIL PROTECTED]> wrote: Hi Bill I do not think you understand TSM As well as you think. Read the admin manual about the SET DRMCOPYSTGPOOL and SET DRMPRIMSTGPOOL, This means the same thing, the only difference is that you have a copy of data onsite and another copy offsite when you have a copy pool. A primary pool data taken offsite means you only have one copy. TSM allows you to have a copy or a primary storage pool DR managed. Bill please do not confuse people on the NET when you do not understand the product or software. Thks Sean -Original Message- From: Bill Boyer [mailto:[EMAIL PROTECTED] Sent: 02 April 2004 10:43 PM To: [EMAIL PROTECTED] Subject: Re: vaulting primary storage pool volumes Have you actually used this option??? From my reading of the admin guide and reference all specifying DRMPRIMSTGPOOL does is cause DRM to create the recovery steps in the recovery plan file for those primary pools specified. It does not include any primay storage pool volumes in the DRMEDIA catagory. Unless I'm reading it wrong... Bill Boyer DSS, Inc. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Behalf Of tsmadmin account for Excaliber Business Solutions Sent: Friday, April 02, 2004 8:45 AM To: [EMAIL PROTECTED] Subject: Re: vaulting primary storage pool volumes Importance: High Hi With the option of set drmprimstgpool, you do not have to do any of the below. It would be just like setting up the DRM for Copystgpools. DRM manages and dictates which tapes would have to go offsite and which tapes comes back onsite. You would not encounter problems like what you are having as DRM would show you which tapes are empty/scratched. Let DRM manage your primary storage pool volumes. This is what TSM is designed to do. You do not have to re-invent the process. The process is done for you. With DRM managing your primary storage pools, look at the following option: 1) move drmedia 2) checkin libvol This will fix all your problems... Allow DRM to do the work for you. At the moment you would have to do a complete manual inventory of whats onsite and whats offsite to get all tapes/carts back in-sync. The way you do this is by checking in the primary storage pool what volumes have valid data or valid carts to what you have offsite. This should fix your problem and after this follow the DRM process. Thks Sean -Original Message- From: Uwe Schreiber [mailto:[EMAIL PROTECTED] Sent: Friday, April 02, 2004 3:13 PM To: [EMAIL PROTECTED] Subject: Re: vaulting primary storage pool volumes Hi, i'am using the move media functionality to vault primary stgpool volumes created by TDP for R/3. i use the following commands in a checkout-script for the checkout mov med * stg=tape_db_t1 wherestatu=full wheresta=mountablei ovfloc=Tresor-Securitas days=0 remove=bulk acc=readw mov med * stg=tape_db_t2 wheresta=mountablei ovfloc=Tresor-Securitas days=0 remove=bulk acc=readw mov med * stg=tape_db_t3 wheresta=mountablei ovfloc=Tresor-Securitas days=0 remove=bulk acc=readw -- i build a list of empty tapes for this diskpools via q med * stg=tape_db_t* wherestatu=empty wherest=mountablen --- a special checkin-script checks wether the requested tapes where checked-in the library and then makes a move media with which the tapes will be deleted from the storagepool and then check them in again as scratch pg /adsmscripts1/checkin_primary | while read line do set $line BAND=`echo $4` CAT=`mtlib -l /dev/lmcp0 -qE -V$BAND | grep category | cut -c29-32` if [ "$CAT" = "FF00" ] then $CMD1 "move media $BAND stg=tape_* wherestate=mountablenotinlib" >> $LOGFILE sleep 3 $CMD1 "checkin libv tsmlib1 $BAND stat=scr devt=3590 checkl=no" >> $LOGFILE echo "" >> $LOGFILE else echo $BAND >> $ERRORFILE fi done Mit freundlichen Gr en / Best Regards Uwe Schreiber [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 02.04.2004 14:03 Please respond to [EMAIL PROTECTED] To [EMAIL PROTECTED] cc Subject
Re: ANE4987E during backup
You don't want to exclude the registry. That won't fix this issue. I am just curiouse if you stopped and started the scheduler service after you add the exclude? If you did then a copy of your entire include/exclude list would help. You might have an include below your exclude that is catching NTUser.Dat. Kevin Godfrey <[EMAIL PROTECTED]> wrote:I am receiving error ANE4987E during client backup. If I look in the activity log on the server I see: ANE4987E (Session: 2155, Node: STORSERV) Error processing '\\storserv\c$\Documents and Settings\NetworkService\NTUSER.DAT': the object is in use by another process I tried doing EXCLUDE "C:\...\NTUSER.DAT" on the client but it didn't help. I thought I might try EXCLUDE.SYSTEMOBJECT "REGISTRY" but I'm not really much of a Windows admin so I don't know if this would help me to get rid of these messages. I know that I don't have to worry too much as I know that the rest of the system got backed up just fine but I would like to get rid of these messages. Does anyone know how? Thanks Kevin - Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway - Enter today
Re: Directory storage pools
I thought that a long time ago a restore had to recover the directories first before it could recover the data. At that time implementing a separate storage pool for directories that stayed on disk made sense in order to speed up recovery. For some time now a restore will lay down a dummy directory if it hits a file that has to be restored before the directory is restored. As a result the need to have directories in a separate pool seems to be less necessary. Still, some people still implementing this separate storage pool for directories when they have many windows clients. Large windows file servers may have millions of directory objects that will be stored in a storage pool. Just like backing up millions of small files if these objects are spread across many tapes the restore will be slower. I have seen that you can cut 5 - 10% off of the restore time when the directories are all on disk. I would still use the DIRMC if you are a shop with many mgmt classes and a lot of windows nodes. Lets say your MGMT class with the longest retention is called "LONG". Your data goes to an MGMT class called "SHORT". If the storage pools defined in both mgmt classes are collocated then the directory data for the node will take up an extra tape in the storage pool defined to "LONG". Multiply that, times enough nodes and it can make a difference. Further, if you have more than one storage pool that has the longest retention then TSM randomly determines which one to bind the data too. Lastly, if a new mgmt class is created that has a longer retention then a lot of rebinding will happen. I looked at what the redbook said I believe the redbook is speaking to an issue that has long since been resolved. Richard Sims <[EMAIL PROTECTED]> wrote: >As per the TSM redbook at: > >http://www.redbooks.ibm.com/redbooks/pdfs/sg245416.pdf > >It suggests use of DISKDIRS and OFFDIRS to store directory information >to avoid restore-time directory reconstruction hits. > >Everything makes sense, including the need to explicitly bind all >directories on a client to the DISKDIRS management class with DIRMC. > >The next question is... *how* do you select ONLY directories for this >management class without selecting any files within them, in dsm.opt? > >(Server is 5.1.8.0 on AIX and clients are 5.1.5.14/15 on Windows, Linux, >Solaris, and AIX.) ... Directories cannot be independently selected for a Backup or Archive operation: they are implicitly backed up or archived along with files unless you cause files only to be operated upon. Perhaps it would be helpful if you posted the essence of what you are trying to achieve. Note that you don't *need* to use DIRMc with Backup: you can use it for "steering" purposes, but otherwise directories are bound to the management class with the longest retention period. Note also that you have a mix of Windows and Unix clients, wherein only the Windows directory info will typically end up in a storage pool: as the redbook says, "On UNIX clients, the directory entries are stored directly in the IBM Tivoli Storage Manager server database" (unless ACLs are involved). With Unix directory info, the DIRMc effects retention choice, but stgpool choice is not a factor. I have notes on this stuff in http://people.bu.edu/rbs/ADSM.QuickFacts , as an adjunct to the primary IBM reference material. Richard Sims - Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway - Enter today
Re: Directory storage pools
>As per the TSM redbook at: > >http://www.redbooks.ibm.com/redbooks/pdfs/sg245416.pdf > >It suggests use of DISKDIRS and OFFDIRS to store directory information >to avoid restore-time directory reconstruction hits. > >Everything makes sense, including the need to explicitly bind all >directories on a client to the DISKDIRS management class with DIRMC. > >The next question is... *how* do you select ONLY directories for this >management class without selecting any files within them, in dsm.opt? > >(Server is 5.1.8.0 on AIX and clients are 5.1.5.14/15 on Windows, Linux, >Solaris, and AIX.) ... Directories cannot be independently selected for a Backup or Archive operation: they are implicitly backed up or archived along with files unless you cause files only to be operated upon. Perhaps it would be helpful if you posted the essence of what you are trying to achieve. Note that you don't *need* to use DIRMc with Backup: you can use it for "steering" purposes, but otherwise directories are bound to the management class with the longest retention period. Note also that you have a mix of Windows and Unix clients, wherein only the Windows directory info will typically end up in a storage pool: as the redbook says, "On UNIX clients, the directory entries are stored directly in the IBM Tivoli Storage Manager server database" (unless ACLs are involved). With Unix directory info, the DIRMc effects retention choice, but stgpool choice is not a factor. I have notes on this stuff in http://people.bu.edu/rbs/ADSM.QuickFacts , as an adjunct to the primary IBM reference material. Richard Sims
Re: Directory storage pools
Hi Dan, it is not neccessary to add a special include for using the DIRMC option. just add the line DIRMC DiskDirs to the dsm.opt, and only directories will be bound to this management-class. Mit freundlichen Grüßen / Best Regards Uwe Schreiber [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 04.04.2004 08:07 Please respond to [EMAIL PROTECTED] To [EMAIL PROTECTED] cc Subject Directory storage pools As per the TSM redbook at: http://www.redbooks.ibm.com/redbooks/pdfs/sg245416.pdf It suggests use of DISKDIRS and OFFDIRS to store directory information to avoid restore-time directory reconstruction hits. Everything makes sense, including the need to explicitly bind all directories on a client to the DISKDIRS management class with DIRMC. The next question is... *how* do you select ONLY directories for this management class without selecting any files within them, in dsm.opt? (Server is 5.1.8.0 on AIX and clients are 5.1.5.14/15 on Windows, Linux, Solaris, and AIX.) I had also checked the TSM 5.1.5 UNIX client reference from: http://publib.boulder.ibm.com/tividd/td/TSMC/GC32-0789-02/en_US/PDF/GC32-0789-02.pdf and read through everything referencing include, exclude, dirmc, but it's still not obvious to me how to select only directory data for use with DIRMC DISKDIRS. I see there's a dirsonly keyword, but how to use it within context of dsm.opt? include / -dirsonly -dirmc diskdirs ? -Dan
