Finally - A Universal Backup Agent!

I was contacted by a representative of Spictera about their SPFS tool for Spectrum Protect. This product allows you to use a local mount on your Linux server as a place to save your backup or application dump that is a direct connection to the IBM Spectrum Protect backend storage. It uses Spectrum Protect API calls and allows you to implement versioning and retention policies just as you would normal file system backups or archives. This product can solve your issues with proprietary applications that IBM does not, and probably never will, support. Now you can backup your MongoDB or SAP HANA a lot easier by using the native backup process built into your application. Currently it only supports the following OS's.

Supported operating systems are:

• CentOS 6 for x86_64
• CentOS 7 for x86_64
• CentOS 8 for x86_64
• Debian 8 for x86_64
• Debian 9 for x86_64
• Red Hat 6 for x86_64, ppc64 be, s390x (zLinux)
• Red Hat 7 for x86_64, ppc64 le, s390x (zLinux)
• Red Hat 8 for x86_64, ppc64 le, s390x (zLinux)
• SuSE 11 for x86_64, ppc64 be, s390x (zLinux)
• SuSE 12 for x86_64, ppc64 le, s390x (zLinux)
• SuSE 15 for x86_64, ppc64 le, s390x (zLinux)
• Ubuntu 14.04 for x86_64, ppc64 le, s390x (zLinux)
• Ubuntu 18.04 for x86_64, ppc64 le, s390x (zLinux)

I would assume if it support CentOS x86_64 you should have no trouble with it on Red Hat. I'll let Spictera confirm that though. I've provided a presentation on the product for your review.

End of the Road?

For those of you who come here periodically and are wondering why content has been lacking, I wanted to let you all know that it is due to my current employment situation. Currently my employer is in the process of replacing Spectrum Protect throughout the company with Commvault. Once the conversion has completed I will be released and so am currently looking for new employment. Since the 8.1.8 upgrade of our servers I have been working steadily on reporting and prepping for the conversion. The initial thought was that I would stay employed and transition to learning Commvault, but that turned out to not be the case. I have enjoyed managing ADSM/TSM/Spectrum Protect environments for the last 22 years but have seen a drop off of its use as IBM has retreated from marketing their products and moved more towards other areas of the IT field. As I have looked for jobs in the Spectrum Protect realm I have noticed that they are rarer than ever, especially with the current situation the world finds itself. I plan to leave the site and up and will post anything you the readers feel will benefit the Spectrum Protect community. Feel free to send me your article for review and if I feel it fits the nature of this website it will be posted. Unfortunately, unless things change I see myself transitioning into a new role with a cloud emphasis and posts here will end unless you all take over the mantle and provide other admins with advice and examples from your own experiences. I have enjoyed posting and helping the community since founding this website and wish you all success going forward.

Error Upgrading to 8.1.8.0

I performed an upgrade today on a server going from 8.1.0.0 to 8.1.8.0 and after the upgrade we encountered the following errors in the actlog as the system was starting.

08/14/2019 11:59:59      ANR9999D_2835836899 InstGetDB2stmtPass1(instr.c:550)                          Thread<404>: Error in fetching DB2 statement stats,                          rc=235908/14/2019 11:59:59      ANR9999D Thread<404> issued message 9999 from:08/14/2019 11:59:59      ANR9999D Thread<404>  0x00000001000365b4 StdPutText08/14/2019 11:59:59      ANR9999D Thread<404>  0x000000010003784c OutDiagToCons08/14/2019 11:59:59      ANR9999D Thread<404>  0x000000010000cf08 outDiagfExt08/14/2019 11:59:59      ANR9999D Thread<404>  0x000000010019d0d0                          IPRA.$InstGetDB2stmtPass108/14/2019 11:59:59      ANR9999D Thread<404>  0x00000001001a15e0 instrumentStart08/14/2019 11:59:59      ANR9999D Thread<404>  0x00000001012d7b98                          AdmInstrumentBegin08/14/2019 11:59:59      ANR9999D Thread<404>  0x00000001008da68c AdmCommandLocal08/14/2019 11:59:59      ANR9999D Thread<404>  0x00000001008d7af0 admCommand08/14/2019 11:59:59      ANR9999D Thread<404>  0x00000001013fbe68 RunCommand08/14/2019 11:59:59      ANR9999D Thread<404>  0x00000001013f7a48                          ServerMonTwentyMinThread08/14/2019 11:59:59      ANR9999D Thread<404>  0x0000000100010648 StartThread

Although the server started, I wanted to make sure this would not cause issues with the instance. I searched the error ANR9999D_2835836899 and found the following IBM APAR notice. It appears that after the upgrade you may have to manually upgrade the DB2 version using the DB2 update tool. While it appears to be a minor issue, I would recommend you check your instances after upgrade to verify whether you need to run the manual steps to resolve the errors. I've included them here for your convenience.

NOTE: I've added a couple commands (in bold) that we have had to add to the process to make it work.

Local fix

Even though the db2-level might be updated to the latest version 11.1.4.4, run the below set of commands
Stop TSM server and issue the following commands as the instance owner.

• db2 start

• db2 force application all

• db2 terminate

• ipclean

login as root user and run

• /opt/tivoli/tsm/db2/instance/db2iupdt -d <instance name>

login as the instance owner ID and issue the command:

• db2updv111 -d TSMDB1

This issue is supposedly fixed in version 8.1.9.0 and higher.

IBM Spectrum Protect 8.1.6 Tier to Cloud by State

A coworker recently did a presentation on Amazon S3 with Netbackup and I went searching for the capabilities available with TSM/Spectrum Protect. It appears as of 8.1.6 they have added some additional features that greatly expand the usage of cloud based storage. Check out this informative demo from IBM.

Q STATUS Question

The company to which I am employed was recently acquired by another company that is a heavy Netbackup user. They bill not based on overall occupancy but on the "Front End Usage" of their servers. I don't know how that works for accurate billing but it's what they do and now we are being asked to provide "Front End Capacity" numbers so they can compare. The problem is ADSM/TSM/SP has always had issues with reporting "active only" data. Just recently I was working with an select IBM provided to pull the active for file systems but they also stated we had to go to the individual application servers to pull DB data. Not fun. So when I recently looked at all the detail of the Q STATUS I noticed the following near the bottom.

                 SUR Occupancy (TB): 703                

            SUR Occupancy Date/Time: 2019-01-07, 10:23:18

            Front-End Capacity (MB): 148.21             

             Front-End Client Count: 408                   

            Front-End Capacity Date: 2019-01-07, 10:23:18

                   Product Offering: IBM Spectrum Protect

According to IBM these last few statements are:

SUR Occupancy (TB)

If you have an IBM Spectrum Protect Suite (SUR) license, this field specifies the SUR occupancy on the server. The SUR occupancy is the amount of space that is used to store data that is managed by the IBM Spectrum Protect products that are included in the SUR bundle.

SUR Occupancy Date/Time

Specifies the date and time when SUR occupancy data was last collected.

Front-End Capacity (MB)

Specifies the amount of primary data that is reported as being backed up by clients. Clients include applications, virtual machines, and systems. This value is used for the front-end licensing model.

Front-End Client Count

Specifies the number of clients that reported capacity usage based on the front-end licensing model.

Front-End Capacity Date

Specifies the date and time when front-end capacity data was last collected.

Product Offering

Specifies a product offering.

So what exactly is the SUR license and does the EE license cover that? How is the data generated because my server reports front-end data at 148MB but if it is actually TB then that would fit more closely with overall capacity as front-end would be about 21% of overall occupancy. IBM obviously has some function to gather front-end numbers so why do they also have us going down the rabbit hold of gathering the data application data from the clients?

Win2K & Win2003 - Data Currently Unavailable On Server

This past weekend we performed a DR test on quit a few servers and discovered a situation that was a wake up call for anyone still using Windows 2000 or Windows 2003. The issue is that when we ran a restore the IBM Spectrum Protect 8.1 server issued a warning on all the files for the particular node with the following message type…

ANE4035W (Session: 79, Node: ODC-WINCS-1-DR)  File '\\od-wincs-1\e$\834\c-oh\files-20170823-123000' currently unavailable on server.

The tape was in a readonly state and accessible by the library so it was not a tape unavailable problem. I then querried the file and ran some tests suggested by IBM in the following link

http://www-01.ibm.com/support/docview.wss?uid=swg21249032

The data is present and on tape but TSM will not restore it. (See the queries below) IBM would not help us because the OS is unsupported as is the TSM client. We could not restore the System State, System Services, or any of the Data to the DR replica. What we could do is access the data from a supported client level on a supported OS level (i.e. TSM Client 6.4 from a Windows 2008 server). We were unable to recover the Win2K/Win2003 servers during the DR test and unfortunately I know many companies out there still have some of these servers in their environment. It's time to upgrade! Your data is at risk!

tsm: OMATSM02>select * from backups where node_name='ODC-WINCS-1-DR' and FILESPACE_ID=1 and hl_name=upper('\834\c-oh\') and LL_NAME=upper('files-20170823-123000')

      NODE_NAME: ODC-WINCS-1-DR
FILESPACE_NAME: \\od-wincs-1\e$
   FILESPACE_ID: 1
          STATE: ACTIVE_VERSION
           TYPE: DIR
        HL_NAME: \834\C-OH\
        LL_NAME: FILES-20170823-123000
      OBJECT_ID: 11926208445
    BACKUP_DATE: 2018-08-10 03:04:37.000000
DEACTIVATE_DATE:
          OWNER:
     CLASS_NAME: WIN-DR-MC
    ACTUAL_SIZE:

tsm: OMATSM02>show bfo 11926208445

Bitfile Object: 11926208445
  Active
**Sub-bitfile 11926208445 is stored in the following aggregate(s)
Super-bitfile: 11926199674, Offset: 26157087, Length 735, Deduped: F


tsm: OMATSM02>show bfo 11926199674

Bitfile Object: 11926199674
**Super-bitfile 11926199674 contains following aggregated bitfiles,
Bitfile Id, offset, length, active state or owner, link bfid
11926199674   0             8732          Active
11926199676   8732          1527          Active
.
.
.
11926208946   26573407      5510          Active
11926208947   26578917      49168         Active

**Sub-bitfile 11926199674 is stored in the following aggregate(s)
  Super-bitfile: 11926199674, Offset: 0, Length 8732, Deduped: F

**Archival Bitfile Entry
  Bitfile Type: PRIMARY  Storage Format: 22
  Bitfile Size: 26631381  Number of Segments: 1, flags: 0
  Storage Pool ID: 33  Volume ID: 22903  Volume Name: L42803


tsm: OMATSM02>q vol L42803 f=d

                   Volume Name: L42803
             Storage Pool Name: WIN-DR-TAPE
             Device Class Name: IBM-LTO-4
            Estimated Capacity: 4.2 T
       Scaled Capacity Applied:
                      Pct Util: 100.0
                 Volume Status: Full
                        Access: Read-Only
        Pct. Reclaimable Space: 0.0
               Scratch Volume?: Yes
               In Error State?: No
      Number of Writable Sides: 1
       Number of Times Mounted: 227
             Write Pass Number: 1
     Approx. Date Last Written: 08/12/18   16:44:25
        Approx. Date Last Read: 08/25/18   22:06:34
           Date Became Pending:
        Number of Write Errors: 0
         Number of Read Errors: 0
               Volume Location:
Volume is MVS Lanfree Capable : No
Last Update by (administrator): CSMALL
         Last Update Date/Time: 08/25/18   20:29:37
          Begin Reclaim Period:
            End Reclaim Period:
  Drive Encryption Key Manager: IBM Spectrum Protect
       Logical Block Protected: No



tsm: OMATSM02>q libvol dr-libr L42803

Library Name     Volume Name     Status               Owner          Last Use      Home        Device
                                                                                   Element     Type
------------     -----------     ----------------     ----------     ---------     -------     ------
DR-LIBR          L42803          Private                             Data          1,089

Spectrum Protect Server 8.1.x Paging Space Issue

I thought I would pass this along...I have two Spectrum Protect 8.1.4 instances on the same AIX 7 LPAR that since their upgrade to this version has had frequent exhausting of paging space crashes. We reviewed and checked processes and figured it was an AIX issue. Upon deeper investigation I noticed there were some previous APARs for DB2 exhausting paging space due to a 64k block size. Investigating that further led me to the following APAR for Spectrum Protect 

IT23731: SPECTRUM PROTECT SERVER ON AIX MAY RUN INTO PAGING AND OUT OF MEMORY CONDITION

So to check I ran the following shell command to list the top 10 processes using memory/paging

# svmon -Pt 10 -O summary=basic,unit=MB

Unit: MB

----------------------------------------------------------------

     Pid Command          Inuse      Pin     Pgsp  Virtual

 4391072 db2sysc       74805.10     51.4 15266.27 72775.38

 7274744 db2sysc       71323.35     50.2 15579.61 71796.98

10486106 db2vend       71164.58     47.6 15084.41 71589.28

 4915692 dsmserv       15230.22     49.5  6629.03 20345.98

 2490670 dsmserv        1931.09     49.6   299.12  2197.74

 5701694 db2sysc         632.43     47.6     42.1   732.73

 8126714 db2sysc         569.93     47.6     29.1   665.60

 6553630 db2vend         561.76     47.6     37.0   660.47

 6422602 db2sysc         559.20     47.6     37.2   657.31

 4849682 db2sysc         559.20     47.6     37.2   657.31

So the db2sysc and dsm2vend along with the dsmserv are using up large amounts of paging.

Here is my using in topas

PAGING SPACE
Size,MB   64512
% Used     60
% Free     40

So what's the solution? Restart the TSM instance(s) until you can upgrade to 8.1.5