Jul 08

Server APARs fixed in the IBM Spectrum Protect server Version 8.1 fix pack levels

Info Comments Off on Server APARs fixed in the IBM Spectrum Protect server Version 8.1 fix pack levels

https://www-01.ibm.com/support/docview.wss?uid=swg21998548

written by Bosse

Jun 26

Hardware and Software Requirements: Data Protection for VMware Version 7.1.2

Info, VE Comments Off on Hardware and Software Requirements: Data Protection for VMware Version 7.1.2

Abstract

This document details the Hardware and Software requirements for Tivoli Storage Manager for Virtual Environments: Data Protection for VMware 7.1.2.

Content

The Data Protection for VMware requirements vary by high level functional component. Data Protection for VMware has the following high level functional components:

  • Data Protection for VMware GUI
  • Data Mover
  • Recovery Agent

Note:
All Data Protection for VMware functional components must be at the same Fix Pack level. Within a given Fix Pack level, the interim fix level can differ.

Examples:

  • When upgrading the Data Protection for VMware GUI from 7.1.1 to 7.1.2, all Data Movers and recovery agents must be upgraded to 7.1.2.
  • When upgrading a Data Mover from 7.1.1.1 to 7.1.1.2, it is not required that all other components be upgraded to 7.1.0.2 (but they all must be at 7.1.1.x).

This document is divided into linked sections for ease of navigation. You may use the links below to jump to the desired section of the document.

Supported VMware vSphere versions

Supported VMware vCloud Director versions

Data Protection for VMware GUI supported operating systems

Data Mover supported operating systems

Recovery Agent & Recovery Agent Command Line Interface supported operating systems

Mount proxy supported operating systems

Additional software requirements and limitations

Hardware requirements for Data Protection for VMware

Where to download Tivoli Storage Manager for Virtual Environments 7.1.2

Hardware and Software requirements for other releases of Data Protection for VMware

Supported VMware vSphere versions

The following VMware vSphere versions are supported:

  • vSphere 5.1
  • vSphere 5.5
  • vSphere 6.0

Attention: ESXi 5.1 hosts must be at Update 3 or newer patch or update level. ESXi 5.5 hosts must be at Patch 4 or newer patch or update level. These prerequisite levels address a critical VMware Changed Block Tracking (CBT) integrity issue described in VMware KB 2090639.

Note:

  1. The Data Protection for VMware GUI “IBM Data Protection” extension requires vSphere Web Client version 5.5 update 1 (or later). Update 1 is included in the vSphere 5.5 package.
  2. To view supported vSphere and ESXi host versions, please refer to the following tech note: “Tivoli Storage Manager for Virtual Environments: Data Protection for VMware Data Mover compatibility guide with VMware’s Virtual Disk Development Kit”http://www.ibm.com/support/docview.wss?uid=swg21672351

Supported VMware vCloud Director versions

The following VMware vCloud Director versions are supported:

  • vCloud Director 5.1
  • vCloud Director 5.5

Data Protection for VMware GUI supported operating systems

This functional component integrates the product with the VMware vSphere client in order to back up, restore, and manage virtual machines in the VMware vCenter and includes the Data Protection for VMware command-line interface.

The supported operating systems by platform are detailed below.

Linux x86_64 platform

The following operating systems are supported for the Data Protection for VMware GUI on the Linux x86_64 platform.

  • Red Hat Enterprise Linux (RHEL) 5 Update 6 and later maintenance levels and mod levels: Desktop, Advanced Platform and Server Editions
  • Red Hat Enterprise Linux (RHEL) 6, and later maintenance levels and mod levels: Server Edition
  • Red Hat Enterprise Linux (RHEL) 7, and later maintenance levels and mod levels: Server Edition
  • SUSE Enterprise Linux 11, and later mod levels and Fix Packs: Server Edition

Windows x64 platform

The following operating systems are supported for the Data Protection for VMware GUI on the Windows x64 platform:

  • Windows Server 2008, and later maintenance levels: Standard, Enterprise, Datacenter Editions
  • Windows Server 2008 R2, and later maintenance levels: Standard, Enterprise, Datacenter Editions
  • Windows Server 2012 and later maintenance levels: Essentials, Standard, and Datacenter Editions
  • Windows Server 2012 R2 and later maintenance levels: Essentials, Standard, and Datacenter Editions

Note: Data Protection for VMware GUI provides support for Windows Storage Server 2012 for functionality that is also available and supported by the Data Protection for VMware GUI on the Windows Server 2012 Editions.

Data Mover supported operating systems

The Data Mover is installed on the vStorage Backup Server and enables off-host block level incremental backups. This function is enabled by the installation of the Tivoli Storage Manager (TSM) Backup-Archive Client 7.1.2, and later maintenance levels and Fix Packs. The TSM Backup-Archive Client is a separate prerequisite and is included as a convenience in the Data Protection for VMware 7.1.2 installation package. For Windows it may optionally be installed during TSM for Virtual Environments installation. The TSM Backup-Archive Client may also be downloaded independently – see below for details on additional software requirements and limitations.

Though the TSM Backup-Archive Client supports a wide variety of operating systems, only a subset of those operating systems are supported with TSM for Virtual Environments.

  • The 7.1.2 level of the TSM Backup-Archive client, and later Interim fixes of this Fix Pack, is required with Data Protection for VMware 7.1.2.

WARNING :
The TSM Client API 7.1.2 is also a prerequisite of Data Protection for VMware 7.1.2 and on Windows it is automatically installed as a part of the Data Protection for VMware 7.1.2 installation process. The TSM Backup-Archive Client 7.1.2 is a prerequisite to using the Data Mover function for off-host block level incremental backups. The TSM Backup-Archive Client and TSM Client API levels must remain in sync in your complete environment. Therefore, future updates to either the TSM Backup-Archive Client or the TSM Client API require the other component to be updated at the same time. I.e. if you install a new Fix Pack level of the TSM Backup-Archive client, you need to upgrade the TSM Client API to the exact same level on your Data Protection for VMware systems and vice versa. See also ” Upgrading to Tivoli Storage Manager for Virtual Environments Version 7.1.2

The VMware Virtual Disk Development Kit (VDDK) version 6.0 runtime files are used for backing up virtual machines by the Data Mover. Data Mover / TSM Backup-Archive Client with Data Protection for VMware supports the operating systems listed below, as long as they are also supported by VDDK version 6.0. For updates on supported OSes, known issues and limitations regarding VDDK 6.0 see the VMware web site.

The Data Protection for VMware Data Mover utilizes VMware’s Virtual Disk Development Kit (VDDK) API’s to open, close, read and write virtual disk data (VMDKs). To determine the level of VDDK used in each level of Data Protection for VMware, as well as compatible ESX/ESXi builds supported by the VDDK level, please refer to the tech note:
Tivoli Storage Manager for Virtual Environments: Data Protection for VMware Data Mover compatibility guide with VMware’s Virtual Disk Development Kit
located here http://www.ibm.com/support/docview.wss?uid=swg21672351

The supported operating systems by platform for the Data Mover / TSM Backup-Archive Client with Data Protection for VMware are detailed below.

Linux x86_64 platform

The following operating systems are supported for the Data Mover on the Linux x86_64 platform:

  • Red Hat Enterprise Linux (RHEL) 6 Update 6: Client and Server Editions
  • Red Hat Enterprise Linux (RHEL) 7.0: Client and Server Editions
  • SUSE Enterprise Linux 11 SP3: Desktop and Server Editions
  • SUSE Enterprise Linux 12: Desktop and Server Editions

Windows x64 platform

The following operating systems are supported for the Data Mover on the Windows x64 platform:

  • Windows Server 2008 R2: Standard, Enterprise, Datacenter, Storage Server, Storage Server R2, Small Business Server, Essential Business Server, and Web Editions
  • Windows Server 2012 Essentials, Standard, and Datacenter Editions
  • Windows Server 2012 R2 Essentials, Standard, and Datacenter Editions

Note: Data Mover provides support for Windows Storage Server 2012 for functionality that is also available and supported by Data Mover on the Windows Server 2012 Editions.

Recovery Agent supported op erating systems

This function provides virtual mount and instant restore capabilities. The supported operating systems by platform are detailed below.

Linux x86_64 Platform

The following operating systems are supported for the Recovery Agent on the Linux x86_64 platform:

  • Red Hat Enterprise Linux (RHEL) 51 Update 2, and later maintenance levels and mod levels: Desktop and Advanced Platform Editions
  • Red Hat Enterprise Linux (RHEL) 61, and later maintenance levels and mod levels: Client and Server Editions
  • Red Hat Enterprise Linux (RHEL) 7: Client and Server Editions
  • SUSE Enterprise Linux 11, and later maintenance levels and mod levels: Desktop and Server Editions
  • SUSE Enterprise Linux 12, and later maintenance levels and mod levels: Desktop and Server Editions


Note:

  1. Requires the following minimum packages and their dependencies:
  • compat-db-4.6.21-15
  • libXp-1.0.0-15.1
  • libXmu-1.0.5-1
  • libXtst-1.0.99.2-3
  • pam-1.1.1-4
  • libXft-2.1.13-4.1
  • gtk2-2.18.9-4
  • gtk2-engines-2.18.4-5

The Recovery Agent Command Line Interface (CLI) is not supported on the Linux x86_64 platform.

Windows x86 Platform

The following operating systems are supported for the Recovery Agent on the Windows x86 platform:

  • Windows Server 2008 SP1, and later maintenance levels: Standard, Enterprise, Datacenter, Storage Server, Storage Server R2, Small Business Server, Essential Business Server, and Web Editions
  • Windows 7, and later maintenance levels: Enterprise, Home Premium, Professional, Starter, and Ultimate Editions
  • Windows 8, Professional and Enterprise Editions
  • Windows 8.1, Professional and Enterprise Editions


Note:
If you use Active Directory with Microsoft Windows 2008 or Microsoft Windows 2008 R2, install the hot fix associated with Microsoft Knowledge Base article 970770 at:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;970770

Windows x64 Platform

The following operating systems are supported for the Recovery Agent on the Windows x64 platform:

  • Windows Server 2008 SP11, and later maintenance levels: Standard, Enterprise, Datacenter, Storage Server, Storage Server R2, Small Business Server, Essential Business Server, and Web Editions
  • Windows Server 2008 R21, and later maintenance levels: Standard, Enterprise, Datacenter, Storage Server, Storage Server R2, Small Business Server, Essential Business Server, and Web Editions
  • Windows 7, and later maintenance levels: Enterprise, Home Premium, Professional, and Ultimate Editions
  • Windows 8, Professional and Enterprise Editions
  • Windows 8.1, Professional and Enterprise Editions
  • Windows Server 20122 Essentials, Standard, and Datacenter Editions
  • Windows Server 2012 R22 Essentials, Standard, and Datacenter Editions


Notes:

  1. If you use Active Directory with Microsoft Windows 2008 or Microsoft Windows 2008 R2, install the hot fix associated with Microsoft Knowledge Base article 970770 at: http://support.microsoft.com/default.aspx?scid=kb;EN-US;970770
  2. Recovery Agent & Recovery Agent Command Line Interface plug-in provides support for Windows Storage Server 2012 for functionality that is also available and supported by Recovery Agent & Recovery Agent Command Line Interface on the Windows Server 2012 Editions.

Mount proxy supported operating systems

A mount proxy represents the Linux or Windows system that provides access to virtual machine disks and requires an iSCSI connection. Mount proxy systems are required when using the Data Protection for VMware vSphere GUI Mount wizard (introduced in Version 7.1.1) to mount a backed up virtual machine disk. The user has the option to automatically create shares (either CIFS or NFS) of the mounted volumes for a file-level restore operation.

When mounting a Windows virtual machine, a Windows mount proxy system is required. When mounting a Linux virtual machine, a pair of Windows and Linux mount proxy systems is required.

For a Linux mount proxy system, the following applications must be installed and configured:

  • Tivoli Storage Manager Backup-Archive client Version 7.1.2.

Note: The iSCSI service must be configured and running during the virtual machine disk mount operation and the file-level restore operation.
By default, the iSCSI service is started manually. If the system where this service is running restarts, the iSCSI service must be restarted manually.

For a Microsoft Windows mount proxy system, the following applications must be installed and configured:

  • Tivoli® Storage Manager Backup-Archive client Version 7.1.2.
  • Tivoli Storage Manager for Virtual Environments Version 7.1.2: Tivoli Storage Manager recovery agent.

Note: The iSCSI Initiator service must be running during the virtual machine disk mount operation and the file-level restore operation.
By default, the iSCSI service is started manually. If the system where this service is running restarts, the iSCSI service must be restarted manually.

Data Protection for VMware requires the following operating system levels as mount proxy systems:

Linux x86_64 platform

  • Red Hat Enterprise Linux (RHEL) 6 Update 3 and Update 4: Client and Server Editions
  • Red Hat Enterprise Linux (RHEL) 7: Client and Server Editions
  • SUSE Enterprise Linux 11 SP3: Desktop and Server Editions
  • SUSE Enterprise Linux 12 : Desktop and Server Editions

Windows x64 platform

  • Windows Server 2008 R2: all Editions
  • Windows Server 2012 all Editions
  • Windows Server 2012 R2 all Editions

Additional software requirements and limitations

The following additional software is required to use Data Protection for VMware:

  • Tivoli Storage Manager (TSM Server) 6.2 and later interim fixes and Fix Packs
  • Tivoli Storage Manager (TSM Server) 6.3 and later interim fixes and Fix Packs
  • Tivoli Storage Manager (TSM Server) 7.1 and later interim fixes and Fix Packs

TIP: TSM Client/API and Server compatibility information is located in the IBM Tivoli Storage Manager Server/Client Compatibility and Upgrade Considerations tech note located here:
http://www.ibm.com/support/docview.wss?uid=swg21053218

  • Tivoli Storage Manager (TSM) Server 6.3.4, and later maintenance levels, Fix Packs, releases, and versions is required for use of following features that are new to Data Protection for VMware 7.1:
    • Show VMs with a backup report
    • Show failures from the most recent backup report
    • Show all backup failures report
    • Show backup history view
    • Show all history view
    • Show failed VMs view
    • Show all VMs view
  • Tivoli Storage Manager (TSM) Server 7.1.0, and later maintenance levels, Fix Packs, releases, and versions is required for use of the following features that are new to Data Protection for VMware 7.1:
    • Application protection reporting

Data Protection for VMware components support or require the following applications:

  • The Recovery Agent and Data Protection for VMware GUI require the following supporting applications on Linux:
    • Perl version 5
    • mdadm 2.6 tool for managing Linux Software RAID arrays
    • iSCSI Initiator 6.2 for Linux package
    • lsscsi command version 0.23
    • iscsiadm utility 0.10
    • Secure Shell (SSH) client for Linux 0.1
  • The following browsers are supported with the Data Protection for VMware GUI
    • Microsoft Internet Explorer version 9, 10 or 11 on Windows
      If launching the Data Protection for VMware GUI as a plug-in from the VMware vSphere Desktop Client, Microsoft Internet Explorer version 9, 10 or 11 must be installed on the system where the desktop client is installed.
      Note: vSphere Desktop Client plugin is not supported with vSphere 6.0
    • Google Chrome 13 or later on Windows and Linux
    • Mozilla Firefox 10 Extended Service Release or later on Windows and Linux
  • Application protection for VM guests is supported:
    • on the vStorage Backup server for the following platforms:
      • Microsoft Windows 2008 (64-bit)
      • Microsoft Windows 2008 R2 (64-bit)
      • Microsoft Windows 2012 (64-bit)
      • Linux 64-bit platforms
      • VMware ESX 5.x or later (Windows, Linux)
    • for the following applications:
      • Microsoft Exchange Server 2010
      • Microsoft Exchange Server 2013
      • Microsoft SQL Server 2008 (64-bit)
      • Microsoft SQL Server 2008 R2
      • Microsoft SQL Server 2012
      • Microsoft SQL Server 2014

Hardware requirements for Data Protection for VMware

Hardware requirements vary and depend on the following items:

  • Number of protected servers
  • Number of protected volumes
  • Data set sizes
  • LAN and SAN connectivity

The following table describes the hardware requirements that are needed to install Data Protection for VMware.

Component Minimal requirement Preferred
System IntelPentium D 3 GHz Dual Core processor or compatible Not applicable
Memory 2 GB RAM, 2 GB virtual
address space
Not applicable
Available hard disk 200 MB for ‘Documents and
Settings’ folder
2 GB
NIC Card 1 NIC – 100 Mbps 1 NIC – 1 Gbps

Where to download Tivoli Storage Manager for Virtual Environments 7.1.2

The Tivoli Storage Manager for Virtual Environments download document provides information about how and where to obtain the Tivoli Storage Manager for Virtual Environments 7.1.2 package. The information is located at: http://www.ibm.com/support/docview.wss?uid=swg24039450

TIP: Data Protection for VMware 7.1.2 is a component of Tivoli Storage Manager for Virtual Environments 7.1.2

Hardware and Software requirements for other releases of Data Protection for VMware

The Hardware and Software requirements for other releases and Fix Packs for all Tivoli Storage Manager Data Protection for Virtual Environment components are located in the “Tivoli Storage Manager for Virtual Environments – All Requirements Doc” located at:
http://www.ibm.com/support/docview.wss?uid=swg21505139

Related information

All Requirements Doc
Download Tivoli Storage Manager for Virtual Environment

written by Bosse

Mar 16

Auditing a Tivoli Storage Manager deduplicated storage pool

Info Comments Off on Auditing a Tivoli Storage Manager deduplicated storage pool

Problem(Abstract)

Under some circumstances, an audit of a deduplicated storage pool might be necessary. A utility is now available that can be used to audit the deduplication tables to ensure referential integrity, proper chunk linkage, and cleanup of previously-marked, damaged files.

Symptom

The following messages are primary indicators of a potential problem within the deduplication catalog:

ANR4895E ANR1165E ANR1529I ANR1162W

 

Cause

The most common cause of invalidated links within a deduplicated storage pool is the forcible removal of data chunks via the DELETE VOLUME XXXXXX DISCARDDATA=YES command. This command will remove data chunks from the database/media regardless of dependencies within the catalog, which will create invalidated links. As a result, you must follow the DELETE VOLUME DISCARDD=YES command with an audit against the ANR4589E message to cleanup the invalidated links. Until the audit is run, you will see ANR4589E or ANR1162W messages in the activity log that indicates that there are invalidated links.
Another potential cause of invalidated link and referential integrity errors is from DB2 table damage that can occur from a hardware failure. As a result, you can use the DB2DART utility in order to restore structural integrity. Then, you can use the dedupAuditTool perl script, attached to this document, to resolve referential integrity gaps.
The following list include APARs to describe the problem that links can be invalidated during data movement operations:
IC90390 IC96993
It is recommended that the version of the server is at 6.3.4.210 or higher to prevent the problems that are documented in the APARs from occurring in your deduplication environment.

Environment

The problem affects Tivoli Storage Manager servers with a DEVT=FILE storage pool that has deduplication enabled. The data can be deduplicated either by client-side or server-side (Identify).

 

Diagnosing the problem

Use the dedupAuditTool Perl script that is attached to this document.

 

Resolving the problem

 

Overview

As noted in the Abstract area of this document, there can be various reasons for encountering server messages that indicate damage within a deduplicated storage pool. The first step to resolving any deduplication catalog inconsistency is to run an analyzer against the storage pool to determine where the problem might be. Then you would complete the steps to resolve the error. The attached dedupAuditTool.pl script does the analyzing and cleanup to ensure the quickest resolution possible.

The dedupAuditTool.pl is a perl script, which is broken in to 2 audit phases. The first phase is called an ANALYSIS phase and its designed to accept environment and symptom information from the user. With this information, the tool interrogates the various Tivoli Storage Manager tables that are associated with the given symptom that was specified. You are prompted to either create an audit report or proceed directly to the RECOVERY phase. The recovery phase is responsible for either removing the damage, restoring from a copy source, or potentially both, depending on the salvage ability for each given object.

 

Script Details
General Script Information:

  • Perl must be installed on the system where the Tivoli Storage Manager server resides. Because the Perl script interrogates the DB2 database directly, it must be run from this system. To obtain code for the Perl installation, go to http://www.perl.org
  • The tool must be run with a user id that has access to the DB2 instance.
  • The instance user must have FULL read/write access to the directory where the script is being executed and the directory where the client is installed (i.e. /opt/tivoli/tsm/client/ba/bin64).
  • The tool requires access to both DB2 and Tivoli Storage Manager via the dsmadmc and DB2 CLIs.
  • You must use Perl 5.8.0 or higher (A Perl interpreter can be download from – www.perl.org).
  • Two different scripts are available depending on which interpreter is available

– dedupAuditTool.pl (5.10 or higher) – dedupAuditTool_perl_v580 (5.8.0 – 5.10)

  • The tool is an interactive script. It does not accept command line parameters.
  • The tool is a multi-phase script – Environment Setup, Audit Tool Setup, Audit Analysis and Recovery(Cleanup).

How Is The Script Executed?: perl dedupAuditTool.pl
Important Usage Notes:

  • If a DELETE VOLUME DISCARDDATA=YES command has been issued against a volume that is located in a deduplicated storage pool, this script should be run immediately afterwards with the ANR4895E symptom to resolve all of the invalidated links.
  • The script should only be run in a deduplicated environment for which the following requirements are all true (the script will prompt for these as well):

– A current FULL database backup is available – All data movement and expiration activity for the deduplicated storage pool has been quiesced
– The Tivoli Storage Manager server is at 6.3.4.210 higher

  • It is typically recommended to run the RECOVERY mode with BOTH so that all restorable objects are recovered from a copy source and all non-restorable objects are removed. This will result in the fastest and most straightforward cleanup possible.

Audit Details Audit Symptom Categories and Coverage Details: – ANR4895E An invalidated deduplication chunk link has been found.
– ANR1165E and ANR1162W A damaged file has been found in a deduplicated storage pool.
– ANR1529I
Damaged and expired base chunks have been found in a deduplicated storage pool.
– MISSING_EXTENT_ENTRY Category that checks for any deduplicated object which no longer cataloged.
– ORPHANED_EXTENT
Category that checks for an invalidated chunk that only exists in the deduplication catalog table.
– INVALIDATED_LINKS Category that checks for any invalidated links that might exist in the deduplicated storage pool.
– MISSING_EXTENT_ENTRY Category that checks for any deduplicated object which no longer has an extent in the deduplication
catalog.
– MISSING_AF_ENTRIES Category that checks for any deduplicated extent that no longer has a corresponding entry in the volume tracking table.
– MISSING_VOL_ENTRIES Category that checks for a deduplicated object that no longer has a valid volume associated to it.
– ZERO_LENGTH_CHUNKS Category that checks for any base data chunks (not links) that no longer contain actual storage references.
– MISSING_CHUNKS Category that checks for an object that has been deduplicated but no longer has entries in the database deduplication catalog.
– MISSING_CHUNKS_EXTENDED Category that performs additional resource intensive checks beyond what the MISSING_CHUNKS symptom covers. – ALL The ALL category will go through all of the above symptoms plus a few others that are not documented above. This category should only be run as part of a health check and can run for a long period of time, depending on the size of the database and the deduplicated storage pool.
Audit Phase Options: * The deduplication catalog can be analyzed by either auditing a symptom or by processing a previously generated audit file
Recovery Phase Options: * The following cleanup phase options are available. The cleanup phase occurs after the analysis
is completed: – Either an audit file can be generated, for future processing, or the script can enter a recovery procedure. If the recovery procedure is chosen, the following modes are available: – Restore/Delete
All invalid data is attempted for restoration. If data cannot be restored it will then be removed from the Tivoli Storage Manager server. – Restore Only All invalid data is attempted for restoration from a copy pool. – Delete Only All invalid data will be removed from the Tivoli Storage Manager server. – Preview All recovery steps are taken, including restoration and deletion, but no action is performed. The console will display each step that would be covered if the Recovery was executed without PREVIEW.

Script Examples

Hide details for AUDIT OF ANR4895E SYMPTOM (Invalid Links Found) AUDIT OF ANR4895E SYMPTOM (Invalid Links Found)
***********************************************************************
Welcome to dedupAuditTool! The runtime perl version: 5.010001
Attention!!
Before proceeding with the cleanup procedure, make sure the following statements are true:
– A current FULL database backup is available!
– All data movement and deletion activity in the deduplicated pool has been quiesced! This would include the following processes:
Expiration Reclamation Migration Move Data Move NodeData
– The Tivoli Storage Manager server is at 6.3.4.210 higher!
************************************************************************
Continue with the deduplication audit? (Y/N): <def: N>: Y

***********************************************************
Phase 1: Environment Setup
***********************************************************
Input the db2 database name <def: TSMDB1>: MGSUNC
Input the db2 schema name <def: TSMDB1>: TSMDB1
The connection to DB2 succeeded Input the dsmadmc path(double quote the path) < def: “/opt/tivoli/tsm/client/ba/bin64”>:
Input the admin name <def: admin>:admin Input the password for admin <def: admin>:admin Input the option file(double quote the path) < def: “/opt/tivoli/tsm/client/ba/bin64/dsm.opt”>: Connection to DISCO_A_SRV succeeded.
Finding all deduplicated storage pools
. .
***********************************
DEDUPLICATED STORAGE POOLS:
FILEPOOL
FILENEXTPOOL ***********************************
Input the poolid or poolname to process <def: deduppool>: FILEPOOL The DB2 command has started The DB2 command succeeded Conversion between poolid(4) AND poolname(FILEPOOL) succeeded
***********************************************************
Phase 2: Dedup Audit Tool Setup
***********************************************************
Audit with script[A] or by previously generated audit file[F]? <def: A>: A
Would you like to see all available symptoms that can be audited? <def: Y>: Y
*********AUDIT SYMPTOMS********* ALL (INCLUDES EVERYTHING BELOW): ANR4895E ANR1165E ANR1529I
ANR1162W MISSING_EXTENT_ENTRIES
MISSING_SEGMENT_ENTRIES MISSING_AF_ENTRIES
ORPHANED_EXTENT MISSING_VOL_ENTRIES
INVALIDATED_LINKS ZERO_LENGTH_CHUNKS
MISSING_CHUNKS MISSING_CHUNKS_EXTENDED
*********AUDIT SYMPTOMS*********
Input the symptom, or error message, you want to check <def: ANR4895E>: ANR4895E
Checking to see if there are active dedup deletions occurring.
If there are, the audit will wait until the deletions are finished.

Command #1 to perform is: tsm show dedupdeleteinfo
The TSM command has started The TSM command succeeded
Deduplicated chunks are not being deleted at this time, proceeding….
***********************************************************
Phase 3: Auditing Deduplicated Storage Pool FILEPOOL
***********************************************************
The dedup audit tool is running in ANR4895E mode The audit is in processing phase 1: ZERO_LENGTH_BASE_CHUNKS The DB2 command has started The DB2 command succeeded The audit scan found nothing wrong in phase 1: ZERO_LENGTH_BASE_CHUNKS
The audit is in processing phase 2: INVALIDATED_DEDUP_LINKS The DB2 command has started The DB2 command succeeded The audit scan has detected a potential problem in phase 2: INVALIDATED_DEDUP_LINKS!
The audit is in processing phase 3: DAMAGED_DATA The DB2 command has started The DB2 command succeeded The audit scan found nothing wrong in phase 3: DAMAGED_DATA

***********************************************************
Phase 4: Cleanup of the Deduplicated Storage Pool Cleanup procedures to perform include: INVALIDATED_DEDUP_LINKS
***********************************************************
Perform recovery procedure[RP] or generate an audit file[AF] <def: AF>: AF Input the report file name <def: reportdedup.out>: The report file has been generated.
Check reportdedup.out for the results.

Hide details for EXAMPLE OF AUDIT FILE (Invalid Links Found) EXAMPLE OF AUDIT FILE (Invalid Links Found)
******************************************************************
SYMPTOM: INVALIDATED_DEDUP_LINKS DB2SQL: “select count(*) from bf_bitfile_extents bfbe where bfbe.srvid=0 and bfb
e.poolid=4 and bfbe.linkbfid=9223372036854775807″ RESULT: 10 STORAGE POOL NAME(POOLID): FILEPOOL(4)
******************************************************************

Hide details for RECOVERY OF INVALID LINKS (Using Audit File) RECOVERY OF INVALID LINKS (Using Audit File)
***********************************************************************
Welcome to dedupAuditTool! The runtime perl version: 5.010001
Attention!!
Before proceeding with the cleanup procedure, make sure the following statements are true:
– A current FULL database backup is available!
– All data movement and deletion activity in the deduplicated pool has been quiesced! This would include the following processes:
Expiration Reclamation Migration Move Data Move NodeData
– The Tivoli Storage Manager server is at 6.3.4.210 higher!
************************************************************************
Continue with the deduplication audit? (Y/N): <def: N>: Y

***********************************************************
Phase 1: Environment Setup
***********************************************************
Input the db2 database name <def: TSMDB1>: MGSUNC
Input the db2 schema name <def: TSMDB1>: TSMDB1
The connection to DB2 succeeded Input the dsmadmc path(double quote the path) < def: “/opt/tivoli/tsm/client/ba/bin64”>:
Input the admin name <def: admin>: ADMIN Input the password for admin <def: admin>: ADMIN Input the option file(double quote the path) < def: “/opt/tivoli/tsm/client/ba/bin64/dsm.opt”>: Connection to MSISCO_A_SRV succeeded.
Finding all deduplicated storage pools . .
*********************************** DEDUPLICATED STORAGE POOLS:
FILEPOOL FILENEXTPOOL
***********************************
Input the poolid or poolname to process <def: deduppool>: FILEPOOL The DB2 command has started The DB2 command succeeded Conversion between poolid(4) AND poolname(FILEPOOL) succeeded
***********************************************************
Phase 2: Dedup Audit Tool Setup
***********************************************************
Audit with script[A] or by previously generated audit file[F]? <def: A>: F Input the report file name < def: reportdedup.out>: reportdedup.out Read report file reportdedup.out … The report file( reportdedup.out ) processing was successful
***********************************************************
Phase 4: Cleanup of the Deduplicated Storage Pool Cleanup procedures to perform include: INVALIDATED_DEDUP_LINKS
***********************************************************
Perform recovery procedure now? <def: N>: Y
showdamagedoutput.out exists from previous audit. Remove the file? (Y/N): <def: Y>: Y
Perform INVALIDATED_DEDUP_LINKS recovery procedure? (Y/N):< def: Y> Y
***********************************************************
Starting recovery procedure for INVALIDATED_DEDUP_LINKS
***********************************************************
Perform restore/delete[B], restore[R], delete[D], preview[P] operation <def: R>: D
Performing DB setup required for recovery operation of the INVALIDATED_DEDUP_LINKS.
Command #1 to perform is: db2 “select ‘show bfo ‘ || bfid from af_damaged where poolid=4” => showobject.mac The DB2 command has started
The DB2 command succeeded
Command #2 to perform is:
tsm -itemcommit macro showobject.mac => showdamagedoutput.out
The TSM command has started The TSM command succeeded
Command #3 to perform is: db2 “delete from AF_DAMAGED where srvid=0 and poolid=4” The DB2 command has started
The DB2 command succeeded
Check the showdamagedoutput.out file for any previously marked damaged files.
Performing the recovery operation for INVALIDATED_DEDUP_LINKS corruption

Command #4 to perform is: db2 “delete from AF_DAMAGED where srvid=0 and poolid=4” The DB2 command has started
The DB2 command succeeded
Command #5 to perform is:
tsm restore stgpool FILEPOOL w=y The TSM command has started The TSM command succeeded
Command #6 to perform is: db2 “select ‘delete object ‘ || cast( bfbf.owner as char(24) ) || ‘ force=yes’ from bf_bitfile_extents bfbe left join bf_aggregated_bitfiles bfbf on ( bfbe.srvid=bfbf.srvid and bfbe.bfid=bfbf.bfid and bfbe.superbfid=bfbf.superbfid ) where bfbe.srvid=0 and bfbe.poolid=4 and bfbe.linkbfid=9223372036854775807 and bfbf.srvid is not NULL group by bfbf.owner” => deleteobject.mac The DB2 command has started
The DB2 command succeeded
Command #7 to perform is:
tsm -itemcommit macro deleteobject.mac The TSM command has started The TSM command succeeded
Command #8 to perform is: tsm show dedupdeleteinfo The TSM command has started The TSM command succeeded Deduplicated chunks are not being deleted at this time, proceeding….
Command #9 to perform is: db2 “insert into AF_DAMAGED ( srvid, bfid, poolid, updator ) (select distinct 0, superbfid, poolid, 2 from bf_bitfile_extents where srvid=0 and poolid=4 and linkbfid=9223372036854775807 and bfid!=9223372036854775807 )” The DB2 command has started
The DB2 command succeeded
Command #10 to perform is:
db2 “select ‘show bfo ‘ || bfid from af_damaged where poolid=4” => showobject.mac The DB2 command has started The DB2 command succeeded
Command #11 to perform is: tsm -itemcommit macro showobject.mac => showdamagedoutput.out The TSM command has started The TSM command succeeded
Check current entries in showdamagedoutput.out for any remaining invalid objects.

Hide details for AUDIT OF ANR4895E SYMPTOM (No Problems Found) AUDIT OF ANR4895E SYMPTOM (No Problems Found)
***********************************************************************
Welcome to dedupAuditTool! The runtime perl version: 5.010001
Attention!!
Before proceeding with the cleanup procedure, make sure the following statements are true:
– A current FULL database backup is available!
– All data movement and deletion activity in the deduplicated pool has been quiesced! This would include the following processes:
Expiration Reclamation Migration Move Data Move NodeData
– The Tivoli Storage Manager server is at 6.3.4.210 higher!
************************************************************************
Continue with the deduplication audit? (Y/N): <def: N>: Y

***********************************************************
Phase 1: Environment Setup
***********************************************************
Input the db2 database name <def: TSMDB1>: MGSUNC
Input the db2 schema name <def: TSMDB1>: TSMDB1
The connection to DB2 succeeded Input the dsmadmc path(double quote the path) < def: “/opt/tivoli/tsm/client/ba/bin64”>:
Input the admin name <def: admin>: ADMIN Input the password for ADMIN <def: admin>: ADMIN Input the option file(double quote the path) < def: “/opt/tivoli/tsm/client/ba/bin64/dsm.opt”>: Connection to MSISCO_A_SRV succeeded.
Finding all deduplicated storage pools . .
*********************************** DEDUPLICATED STORAGE POOLS:
FILEPOOL FILENEXTPOOL
***********************************
Input the poolid or poolname to process <def: deduppool>: FILEPOOL The DB2 command has started The DB2 command succeeded Conversion between poolid(4) AND poolname(FILEPOOL) succeeded
***********************************************************
Phase 2: Dedup Audit Tool Setup
***********************************************************
Audit with script[A] or by previously generated audit file[F]? <def: A>: A
Would you like to see all available symptoms that can be audited? <def: Y>: Y
*********AUDIT SYMPTOMS********* ALL (INCLUDES EVERYTHING BELOW): ANR4895E ANR1165E ANR1529I
ANR1162W MISSING_EXTENT_ENTRIES
MISSING_SEGMENT_ENTRIES MISSING_AF_ENTRIES
ORPHANED_EXTENT MISSING_VOL_ENTRIES
INVALIDATED_LINKS ZERO_LENGTH_CHUNKS
MISSING_CHUNKS MISSING_CHUNKS_EXTENDED
*********AUDIT SYMPTOMS*********
Input the symptom, or error message, you want to check <def: ANR4895E>: ANR4895E
Checking to see if there are active dedup deletions occurring.
If there are, the audit will wait until the deletions are finished.

Command #1 to perform is: tsm show dedupdeleteinfo
The TSM command has started The TSM command succeeded
Deduplicated chunks are not being deleted at this time, proceeding….
***********************************************************
Phase 3: Auditing Deduplicated Storage Pool FILEPOOL
***********************************************************
The dedup audit tool is running in ANR4895E mode The audit is in processing phase 1: ZERO_LENGTH_BASE_CHUNKS The DB2 command has started The DB2 command succeeded The audit scan found nothing wrong in phase 1: ZERO_LENGTH_BASE_CHUNKS
The audit is in processing phase 2: INVALIDATED_DEDUP_LINKS The DB2 command has started The DB2 command succeeded The audit scan found nothing wrong in phase 2: INVALIDATED_DEDUP_LINKS
The audit is in processing phase 3: DAMAGED_DATA The DB2 command has started
The DB2 command succeeded The audit scan found nothing wrong in phase 3: DAMAGED_DATA
No problems were detected by the dedup audit tool for FILEPOOL!

Attached Scripts
dedupAuditTool.pl – Script that requires PERL version 5.10 or higher
dedupAuditTool_v580.pl – Script that requires PERL version 5.8.0 – 5.10
NOTE: If is recommended that dedupAuditTool.pl is used if the 5.10 or higher PERL interpreter is available for the given operating environment.

written by Bosse

Jun 13

HP, IBM, Oracle, Quantum and Tandberg Ultrium Generation 6 (LTO-6) Drive Configuration Information for IBM Tivoli Storage Manager Server

Info Comments Off on HP, IBM, Oracle, Quantum and Tandberg Ultrium Generation 6 (LTO-6) Drive Configuration Information for IBM Tivoli Storage Manager Server

Support information about the following drives is detailed in the sections below.

HP Ultrium 6650 HP Ultrium 6250 IBM TS2360 IBM TS2260 IBM TS1060 IBM Half-High LTO Gen 6 SAS Tape Drive Oracle StorageTek HPLTO6 Oracle StorageTek IBMLTO6 Quantum LTO6 HH SAS Tandberg LTO-6
Required Tivoli Storage Manager versions: Support for these LTO-6 drives is available with the following IBM Tivoli Storage Manager Server versions. Version Release 6.2 – requires Tivoli Storage Manager version 6.2.5 or subsequent maintenance release Version Release 6.3 – requires Tivoli Storage Manager version 6.3.3 or subsequent maintenance releases
Defining a device class:
When defining a device class for an Ultrium 6 drive, use the following values. DEVType=LTO FORMAT=< DRIVE | ULTRIUM6 | ULTRIUM6C | ULTRIUM5 | ULTRIUM5C > DRIVE – The server selects the highest format that is supported by the drive on which a volume is mounted.

ULTRIUM6 – Specifies that Tivoli Storage Manager writes data that uses the ULTRIUM6 recording format. Only Ultrium 6 media can be written to with the ULTRIUM6 format. The capacity of an Ultrium 6 cartridge when the ULTRIUM6 format is used is 2.5 TB.

ULTRIUM6C – Specifies that Tivoli Storage Manager writes data that uses the ULTRIUM6 recording format with compression. Only Ultrium 6 media can be written to with the ULTRIUM6C format. The average capacity of an Ultrium 6 cartridge when the ULTRIUM6C format is used is 6.25 TB.

ULTRIUM5 – Specifies that Tivoli Storage Manager writes data that uses the ULTRIUM5 recording format. Only Ultrium 5 media can be written to with the ULTRIUM5 format. The capacity of an Ultrium 5 cartridge when the ULTRIUM5 format is used is 1.5 TB.

ULTRIUM5C – Specifies that Tivoli Storage Manager writes data that uses the ULTRIUM5 recording format with compression. Only Ultrium 5 media can be written to with the ULTRIUM5C format. The average capacity of an Ultrium 5 cartridge when the ULTRIUM5C format is used is 3 TB.

Examples: DEFine DEVClass devclass_name LIBRary=library_name DEVType=LTOFORMAT=ULTRIUM6 DEFine DEVClass devclass_name LIBRary=library_name DEVType=LTOFORMAT=ULTRIUM6C
Administration Center support: Administration Center support for LTO-6 drives is not available with Tivoli Storage Manager Server version 6.2.5 or 6.3.3. Use the Tivoli Storage Manager Server command line to define LTO-6 drives.
Encryption support: Application Managed Encryption is supported by Tivoli Storage Manager if it is supported by the drive. Check with your hardware vendor to determine whether AME is supported by hardware.
Supported media:
Tivoli Storage Manager Server supports the following media for LTO-6 drives: Ultrium 4 – 800GB Read-Write data cartridge Ultrium 4 – 800GB WORM data cartridge Ultrium 5 – 1.5 TB Read-Write data cartridge Ultrium 5 – 1.5 TB WORM data cartridge Ultrium 6 – 2.5 TB Read-Write data cartridge Ultrium 6 – 2.5 TB WORM data cartridge

Restrictions on WORM media: Pre-labeled WORM media are not allowed. WORM media are not compatible with encryption.
Mixed generation considerations: Ultrium generation 6 drives can read and write to Ultrium generation 6 and generation 5 media, but can only read Ultrium generation 4 media. In a library with an Ultrium generation 6 drive, all Ultrium generation 4 scratch volumes need to be checked out, and all Ultrium generation 4 storage pool volumes need to be updated to read-only.

In a library in which mixed media is not supported by the Tivoli Storage Manager Server, all scratch volumes and volumes with readwrite access must be readable and writable by all drives. If all drives are Ultrium generation 6, readwrite media can be Ultrium generation 5 and generation 6. If Ultrium generation 6 drives are mixed with Ultrium generation 5 drives, all readwrite media must be generation 5.

This is because Ultrium generation 5 drives cannot read or write to Ultrium generation 6 media.

Logical Block Protection: Logical Block Protection is supported by LTO 6 drives. Please see the following tech note for more information on how to use Logical Block Protection and supported drives and firmware versions: http://www.ibm.com/support/docview.wss?uid=swg21568108
Additional information on Logical Block Protection is available from the Tivoli Storage Manager info center: http://pic.dhe.ibm.com/infocenter/tsminfo/v6r4/index.jsp?topic=%2Fcom.ibm.itsm.srv.doc%2Ft_lbp.html

Device Specific Notes:
Supported Device identifications and firmware levels:
HP StoreEver Ultrium 6650 FC Drive ID: HP Ultrium 6-SCSI Firmware: J29D (validated with TSM 6.2.5, 6.3.3 and 6.3.4)
HP StoreEver Ultrium 6650 SAS Drive ID: HP Ultrium 6-SCSI Firmware: 329D (validated with TSM 6.2.5, 6.3.3 and 6.3.4)
HP StoreEver Ultrium 6250 SAS Drive ID: HP Ultrium 6-SCSI Firmware: O2AD (validated with TSM 6.2.5, 6.3.3 and 6.3.4)
IBM Full Height Drive TS2360 Drive ID: IBM ULT3580-TD6 (validated with TSM 6.2.5 and 6.3.3)
IBM Full Height Drive TS1060 Drive ID: IBM ULT3580-TD6 (validated with TSM 6.2.5 and 6.3.3)
IBM Half Height Drive TS2260 Drive ID: IBM ULT3580-HH6 (validated with TSM 6.2.5 and 6.3.3)
IBM Half-High LTO Gen 6 SAS Tape Drive Drive ID: IBM HH LTO Gen 6 Firmware: C9T5 (validated with TSM 6.2.5, 6.3.3, and 6.3.4)
Oracle StorageTek HPLTO6 Drive ID: HP Ultrium 6-SCSI Firmware: J2AS (validated with TSM 6.3.4)
Oracle StorageTek IBMLTO6 Drive ID: IBM ULTRIUM-TD6 Firmware: C9T4 (validated with TSM 6.3.4)
Quantum LTO6 HH SAS Drive ID: QUANTUM ULTRIUM 6 Firmware: 4071 (validated with TSM 6.2.5 and 6.3.4)
Tandberg LTO6 HH FC Drive ID: TANDBERG LTO-6 HH Firmware: 2249 (validated with TSM 6.2.5 and 6.3.4)
Tandberg LTO6 HH SAS Drive ID: TANDBERG LTO-6 HH Firmware: 3249 (validated with TSM 6.2.5 and 6.3.4)
Device Driver: The IBM device driver is required for IBM Ultrium 6 drives. IBM device drivers are available at IBM Fix Central. Choose the following options from the drop-down menus. Product Group -> System Storage System Storage -> Tape systems Tape systems -> Tape drivers and software Tape drivers and software -> Tape device drivers Platform -> select the platform for the device driver that you are looking for.

Related APARs:
Supported platforms:
See “Supported Devices for AIX, HP-UX, Solaris and Windows” or “Supported Devices for Linux” for minimum supported version levels and platforms for these devices. For LTO-6 drives with SAS interface, see Technote 1396706 for supported platforms.

written by Bosse

Nov 29

Relocating Tivoli Storage Manager Server DB2 database instance directories

Info Comments Off on Relocating Tivoli Storage Manager Server DB2 database instance directories

Problem(Abstract)

Is it possible to change the location of the local Tivoli Storage Manager Server DB2 database directory?

Resolving the problem

DB2 provides an utility called ‘db2relocatedb’ that can be used to move the existing DB2 database instance directories to a new location. By default, the local database directory is created on the C: drive. It may be necessary to move the local DB2 database instance directory to another drive with more available space.

For example, assume that the local DB2 database instance directory was initially created on the C: drive, as seen in the output from the ‘db2 list database directory’ command below:
1: Dos Command Prompt, enter ‘db2cmd’ to get a DB2 Command Prompt. 2: You will be running all DB2 commands from this new Command Prompt. 3: Issue the following command to get the current DB2 database details details. db2 list database directory
System Database Directory Number of entries in the directory = 1
Database 1 entry: Database alias = TSMDB1 Database name = TSMDB1 Local database directory = C: Database release level = d.00 Comment = TSM SERVER DATABASE Directory entry type = Indirect Catalog database partition number = 0 Alternate server hostname = Alternate server port number =
To change the local database directory from C: to X:, the following actions will need to be performed :
1. As a precaution, perform a full backup of the Tivoli Storage Manager database.
2. Halt the Tivoli Storage Manager Server and ensure that DB2 is also stopped.
3. Copy/move the existing DB2 database instance directory structure to the new location. For example : copy c:\server1\* x:\server1\*

 Ensure that the original directory structure was successfully copied/moved to the new location.

4. Create the configuration file required by the db2relocatedb utility. The configuration file is where all of the required parameters are defined (eg. database name, database instance, new and old directory paths, etc.). Assuming that the database name is TSMDB1 and the DB2 instance is named SERVER1, the configuration file would be as follows : Filename( reloc.cfg ):
DB_NAME=TSMDB1 DB_PATH=C:,X: INSTANCE=SERVER1

 5. Once the configuration file has been created, issue the db2relocatedb command to update DB2 as to the new location of the local DB2 database instance directory path: db2relocatedb -f < reloc.cfg > NOTE: Refer to the DB2 documentation for additional considerations prior to using the db2relocatedb utility.

written by Bosse

Oct 09

IBM Tivoli Storage Manager Suite for Unified Recovery 6.4 and IBM Tivoli Storage Manager Suite for Unified

Info Comments Off on IBM Tivoli Storage Manager Suite for Unified Recovery 6.4 and IBM Tivoli Storage Manager Suite for Unified

Recovery Entry 6.4 deliver a feature-rich storage management software suite that consists of:

  • IBM Tivoli Storage Manager Extended Edition V6.3.3
  • IBM Tivoli Storage Manager for Databases V6.3.3
  • IBM Tivoli Storage Manager for Enterprise Resource Planning V6.4
  • IBM Tivoli Storage Manager for Mail V6.4
  • IBM Tivoli Storage Manager for Space Management V6.4
  • IBM Tivoli Storage Manager for Storage Area Networks V6.4
  • IBM Tivoli Storage Manager for Virtual Environments V6.4
  • IBM Tivoli Storage Manager FastBack® V6.1
  • IBM Tivoli Storage Manager FastBack for Microsoft Exchange V6.1
  • IBM Tivoli Storage Manager FastBack for Bare Machine Recovery V6.1

Tivoli Storage Manager Suite for Unified Recovery V6.4 offers simplified pricing and licensing based on a per terabyte charge metric for data stored within Tivoli Storage Manager primary storage pools and Tivoli Storage Manager FastBack repositories.

For information about the products in this suite, refer to information shown above for each individual product. For information about the Tivoli Storage Manager FastBack products in this suite and more detail about Tivoli Storage Manager Suite for Unified Recovery, refer to the announcement letters in the Reference information section

written by Bosse

Jul 16

IC65242: DOMINO SERVER MAY NOT RESTART AFTER A FASTBACK BACKUP

Domino, Fatsback, Info Comments Off on IC65242: DOMINO SERVER MAY NOT RESTART AFTER A FASTBACK BACKUP

Error description

  • When backing up a Domino Database using one of the scripts
    provided with the SW, FastBack will wait for the Domino server
    to notify it that the database is stopped.
    In some cases, a delay between the time when the Domino server
    has stopped and the actual change of the data base to a stopped
    state can cause the system to try and restart the Domino
    database prematurely and eventually a failure to restart the
    Domino server will occur.

     

  • Local fix

  • Use updated scripts

     

  • Problem summary

  • ****************************************************************
    * USERS AFFECTED: Users that backup Domino with Fastback *
    * Client *
    ****************************************************************
    * PROBLEM DESCRIPTION: See ERROR DESCRIPTION *
    ****************************************************************
    * RECOMMENDATION: Apply fixing level when available (Use *
    * updated scripts). This problem is *
    * currently projected to be fixed in level *
    * 5.5.7 and 6.11. Note that this is subject *
    * to change at the discretion of IBM *
    ****************************************************************
    *

     

  • Problem conclusion

  • Background: When backing up a Domino Database using one of the
    scripts provided with the SW, FastBack will wait for the
    Domino server to notify it that the database is stopped. In
    some cases, a delay between the time when the Domino server
    has stopped and the actual change of the data base to a
    stopped state can cause the system to try and restart the
    Domino database prematurely and eventually a failure to
    restart the Domino server will occur.Fix: The scripts that are responsible for domino server
    restart modified to fix the problem. 

  • Temporary fix

  • Use updated scripts.
    The scripts can be download from
    http://www-01.ibm.com/support/docview.wss?&uid=swg21417993

     

  • written by Bosse

    Jul 09

    Automating Database Availability Group backups for Exchange 2010

    Info Comments Off on Automating Database Availability Group backups for Exchange 2010
    Question
    How to do I automate a backup scheme for database copies in an a Microsoft Exchange Server 2010 Database Availability Group (DAG) using IBM Tivoli Storage Manager for Mail : Data Protection for Microsoft Exchange Server ?
     
     
    Answer
    When performing backups in a Microsoft Exchange Server 2010 Database Availability Group (DAG) environment, it is recommended to perform the backups on the passive database copies. This helps reduce the resource impact on the production Exchange server when performing backup operations for your enterprise. However, there are instances where a passive database copy is not in a healthy state and the active database copy may need to be used for the backup.The following sample Powershell script automates the backing up of the databases hosted on an Exchange 2010 server in a DAG environment. The script determines if the Exchange 2010 server is a member of a DAG and will back up its databases using the following scheme, consistent with best practices:Backup SchemeThe sample Powershell script uses the following logic for backing up the Exchange 2010 server databases:

    1. Back up all local healthy passive database copies.
    2. Back up all local databases that are not replicated.
    3. Back up all local active database copies where a healthy passive copy is not available.

     

    Note: The Powershell script above is a sample. It is provided as-is.

    The sample Powershell script takes an optional parameter which is the path to a log file. If the parameter is not specified, logging will be directed to a file called “.\backup.log”. The script output is sent to the log file as well as the console.

    Example Output

    2010-06-08 02:45:35 – Server: MYSERVER
    2010-06-08 02:45:38 – Building database backup list…
    2010-06-08 02:45:38 – ==> Backing Up Non Replicated Database ‘Mailbox Database 1’
    2010-06-08 02:45:38 – ==> Backing Up Non Replicated Database ‘Mailbox Database 2’
    2010-06-08 02:45:38 – ==> Skipping Dismounted Non Replicated Database ‘Test Mailbox Database’
    2010-06-08 02:45:38 – ==> Backing Up Non Replicated Database ‘Mailbox Database 3’
    2010-06-08 02:45:38 – ==> Backing Up Healthy Passive Database Copy ‘Mailbox Database 4’
    2010-06-08 02:45:38 – ==> Backing Up Healthy Passive Database Copy ‘Mailbox Database 5’
    2010-06-08 02:45:38 – ==> Backing Up Active Database (No Healthy Copies Found) ‘Mailbox Database 6’
    2010-06-08 02:45:38 – Executing command: ‘C:\Program Files\Tivoli\tsm\TDPExchange\tdpexcc.exe’ BACKUP ‘”Mailbox Database 1″,”Mailbox Database 2″,”Test Mailbox Database”,”Mailbox Database 3″,”Mailbox Database 4″,”Mailbox Database 5″,”Mailbox Database 6″ ‘ FULL /BACKUPMETHOD=VSS /BACKUPDESTINATION=TSM
    2010-06-08 02:47:52 – Backup completed.

    Software Requirements

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

    Running the Sample Powershell Script from a Scheduler

    If you want to run the provided sample Powershell script on a scheduled basis using either the IBM Tivoli Storage Manager central scheduler or the Windows Task Scheduler service, follow these steps:

    1. Create a .cmd or .bat command file to run the sample Powershell script.

    2. Add the following statement to the command file to execute the sample Powershell script correctly:

    PowerShell.exe -command “. ‘C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1’; Connect-ExchangeServer -auto; backupdag.ps1”

    Note: For more information about launching Powershell scripts, please refer to the following Microsoft TechNet Library section titled “Scripting with the Exchange Management Shell”:
    (http://technet.microsoft.com/en-us/library/bb123798.aspx)

    3. Run the script either from the IBM Tivoli Storage Manager central scheduler as described in “Chapter
    6. Using the Tivoli Storage Manager scheduler” of the IBM Tivoli Storage Manager for Mail: Data Protection for Microsoft Exchange Server Installation and User’s Guide V6.1.2:
    (http://www.ibm.com/support/docview.wss?uid=swg27018572)
    or from a Windows Scheduler Task.

    Note: Running from a Windows Scheduler Task requires the following task security settings:

    • Run as a domain administrator or other privileged user task (i.e. not a System Task)
    • Run whether user is logged in or not.
    • Run with highest privileges. 

    Länk to page at IBM

    written by Bosse

    Jul 01

    2TB limit on Fastback

    Info Comments Off on 2TB limit on Fastback
    Abstract
    Information is available for the following five potential data integrity-related issues in the Tivoli Storage Manager FastBack product:
    1. APAR IC64526. (Windows 2008/Vista only) After an Instant Restore for a volume, the next snapshot for that volume might be corrupted.
    2. APAR IC63799. (Disaster Recovery users only) When restoring data from the disaster recovery server, during the final stages of the disaster recovery process for a given chain, a locking mechanism does not lock the files of that chain. As such, if a FastBack Mount, Instant Restore, or Bare Machine Recovery process is started, and the process accesses files that should be locked for the disaster recovery, any data accessed can be corrupted.
    3. APAR IC64238. During an Instant Restore, inconsistent data might be accessed. The issue is that corrupted data might be used during the restore. If corrupted data is used during the restore, data loss occurs.
    4. APAR IC64240. During the cleanup process, a failure might occur. The failure might cause data loss.
    5. APAR IC64414. If the backed-up LUN size is 2 TB or greater, snapshots using Tivoli Storage Manager FastBack are not supported.
     
     
    Content
    For the five potential data integrity-related issues for Tivoli Storage Manager FastBack, more information about the problems, and, if available, a workaround and target fix date, are provided below:
    Issue 1. IC64526 (Windows 2008/Vista only)
    If you use Instant Restore to restore a volume, incremental snapshots taken after the Instant Restore completes might be corrupted. If you use the corrupted snapshots, data loss can occur.Who is affected:
    Customers with Tivoli Storage Manager FastBack Version 5.5.x installed, using Instant Restore to restore protected volumes on systems running either Microsoft Vista or Microsoft Windows 2008.

    Workaround #1:
    After completing an Instant Restore, if an incremental snapshot is taken for any policy containing the volume, do not use any of the subsequent incremental snapshots of the restored volume. You can do either a checkpoint or a full snapshot for all snapshot chains that include this volume. (Remember: A volume might be protected by more than one policy.)

    Complete the following steps:

    •  
      1. From FastBack Manager, go to the Configuration tab.
      2. In the navigation tree, locate the policies.
      3. Right click to select a policy; then, click either Run Check Point or Run Full Snapshot.
        Note: Full snapshots require and use more repository space.

    Workaround #2:
    If you do not want to manually run a checkpoint or full snapshot after each Instant Restore, you can configure the FastBack Client to automatically run a delta block snapshot after the FastBack Client service is restarted, by making a change the FastBack Client configuration file on each system with either Microsoft Windows 2008 or Microsoft Vista, and FastBack Client.

    Complete the following steps:
    1. From a command prompt window, change to the directory with the FastBackClient.ini file. The default path for this file follows: C:\Users\All Users\Tivoli\TSM\FastBack\client
    2. Enter the following command to make a copy of the existing FastBackClient.ini file:

      copy FastBackClient.ini FastBackClient.previous

    This copy is your backup copy.
    3. Using Microsoft WordPad (do not use Notepad), open the FastBackClient.ini file.
    4. Go to the [Save-State] section.
    5. Set the Differential-After-Restart parameter to 0. You can refer to the following sample:

      [Save-State]
      Differential-After-Restart = 0

    The 0 parameter means that the software runs delta block after any restart of the client.
    6. Save and close the FastBackClient.ini file.
    7. Restart the FastBack Client system.

    Note, do not complete the previous steps if you have started a checkpoint or full snapshot from FastBack Manager (described in Workaround #1).

    Fixes:

    Release Vulnerable levels First level with fix within that release
    TSM FastBack 5.5 5.5.0.0 through 5.5.5.119 Target: 5.5.6

    This issue does not affect Tivoli Storage Manager FastBack, Version 6.1.0.0.

    Issue 2. IC63799 (Disaster Recovery Server users only)
    During a disaster recovery process, at the end of the process a locking mechanism does not lock some of the files. If a user starts FastBack Mount, an Instant Restore, or a Bare Machine Recovery and accesses files that should be locked, data that is being restore can become corrupted. If the data is corrupted, data loss can occur.

    Who is affected:
    Anyone who has installed IBM Tivoli Storage Manager FastBack Version 5.5.x and uses the Disaster Recovery Server. The problem occurs when you use FastBack Mount, or run an Instant Restore or Bare Machine Recovery on the Disaster Recovery Server while a disaster recovery task that fails to lock files correctly is running. This problem can also affect any customer that uses FilesX Xpress Restore 3.5.x and uses the Disaster Recovery Server.

    Workaround:
    Complete the following steps:
    1. You may be able to download the following application from the following Microsoft Web site: junction.exe at http://technet.microsoft.com/en-us/sysinternals/bb896768.aspx
    2. Save the junction.exe file to the following location: %ProgramFiles%\Junction\junction.exe
    3. Stop the FastBack Disaster Recovery Service.
    4. From a command line prompt, change to the ftp home directory.
    5. For each branch directory (for example, REP_BranchName), complete the following steps:

    •  
        %Program Files%\Junction\junction.exe <Ftp_root_dir>\REP_BranchName\STAGE <Ftp_root_dir>\REP_BranchName
    • a. Under REP_BranchName, delete the STAGE directory.
      b. Use the junction.exe application to recreate the STAGE directory. To complete this step, enter the following command:

    6. Restart the FastBack Disaster Recovery Server.

    For any REP_BranchName items created in the future, you need to repeat step 5b for the new REP_BranchName item.

    If you want to verify that the junction functionality is working, you can create a file under <Ftp_root_dir>\REP_BranchName\STAGE and verify that the file is seen from the following directory: <Ftp_root_dir>\REP_BranchName

    Fixes:

    Release Vulnerable levels First level with fix within that release
    TSM FastBack 5.5 5.5.0.0 through 5.5.5.119 Target: 5.5.6
    FilesX Xpress Restore 3.5 3.5.165 through 3.5.802 Not planned

    This issue does not affect Tivoli Storage Manager FastBack, Version 6.1.0.0.

    Issue 3. IC64238 (Instant Restore users only)
    During the Instant Restore process, access to the snapshot data in the repository might be denied. For example, a temporary network connectivity issue might restrict access to snapshot data in the repository.

    (Windows 2000, 2003, XP only)
    When access to the snapshot data in the repository is denied, the following message is displayed:

      Read block from source have failed. The problem
      may have been caused by a network failure.
      See log file for more details.
      If the problem was caused by a network failure,
      correct the problem and resume the session.

    (Windows 2008 and Windows Vista only)
    When access to the snapshot data in the repository is denied, the “Read block from source have failed…” message might not be visible. The message is not visible if the system reboots while the Instant Restore process is running. For more details about this issue, you can refer to APAR IC63385.

    You can ensure that this message is displayed by changing the FastBack Mount service mode to manual before launching the Instant Restore process. You can use the Windows Service Manager to make this change.

    (All supported Windows OSs)
    The Instant Restore process is paused until the problem is resolved. After the problem is resolved, you have to manually resume the Instant Restore process.

    When the Instant Restore process is paused, applications can continue to access the volume that is being restored. This access may cause a data loss problem after the Instant Restore process is resumed.

    Who is affected:
    Anyone who uses Instant Restore to recover data with IBM Tivoli Storage Manager FastBack, Version 5.5.x. This problem also affects customer using FilesX Xpress Restore 3.5.x.

    To determine if any data loss has occurred, check the system where the Instant Restore ran. If you identify a problem occurred during an Instant Restore, contact IBM Software Support for Tivoli Storage Manager FastBack.

    Recommendation:
    As an alternative to using Instant Restore, you can use the volume restore process.

    Fixes:

    Release Vulnerable levels First level with fix within that release
    TSM FastBack 5.5 5.5.0.0 through 5.5.5.119 Target: 5.5.6
    FilesX Xpress Restore 3.5 3.5.165 through 3.5.802 Not planned

    This issue does not affect Tivoli Storage Manager FastBack, Version 6.1.0.0.

    Issue 4. IC64240
    When running the cleanup process, Tivoli Storage Manager FastBack might identify a snapshot chain that includes corrupted data. If a chain with corrupted data is detected, by default, the next snapshot that runs creates a full snapshot. This full snapshot is a good back up, but, note, all previous back up data might be corrupted.

    If a snapshot chain that includes corrupted data is identified, snapshots on the chain prior to the full snapshot are available for use. Use these snapshots with caution because using a corrupted chain can result in corrupted data or in data loss.

    Who is affected:
    Anyone who has installed IBM Tivoli Storage Manager FastBack Version 5.5.x or FilesX Xpress Restore 3.5.x.

    This problem also affects anyone who has installed IBM Tivoli Storage Manager FastBack Version 6.1.0.0. For Version 6.1.0.0, a message alerts you to this issue.

    Workaround:
    After a corrupt chain is identified, a message is written to the customer log file. To view the log file, from FastBack Manager, go to the Configuration tab. In the navigation area, there is an entry for the FastBack Server Log. Select this entry to view the log in the main window.

    If a corrupt chain is identified, the following message is in the log file:
    The cleanup process <volume/policy description> failed at a critical point. A repair job will be scheduled to fix the chain.

    (All supported Windows operating systems except Windows 2008)
    If the customer file log is filled with a large amount of data, go to the following directory:

      ../Documents & Settings/All users/application data/Tivoli/TSM/FastBack/server

    Look at the clogxxx.log files and search for the message provided above.

    (Windows 2008 only)

      If the customer file log is filled with a large amount of data, go to the following directory: ..\ProgramData\Tivoli\TSM\FastBack\server

    Look at the clogxxx.log files and search for the message provided above.

    If the customer log file does not include a message about a corrupt chain, you can use the chain to restore data.

    Recommendation:
    Use the Workaround to determine if a corrupt chain has been identified. If the customer log file reports that a chain is corrupted, do not perform a restore of this chain. If you perform a restore using this chain, data loss and / or data corruption occurs (because a snapshot with corrupted data is used).

    If the customer log file reports that a chain is corrupted, before mounting or performing a volume restore, you can use the following procedures to identify the data corruption or data loss issues:

    •  
      1. Run the file system check tool. You might have to refer to the operating system documentation for more help in completing this step.
      2. Run the application consistency check tool. You might have to refer to the operating system documentation for more help in completing this step.

    Fixes:

    Release Vulnerable levels First level with fix within that release
    TSM FastBack 6.1.0 6.1.0.0 Target: 6.1.1
    TSM FastBack 5.5 5.5.0.0 through 5.5.5.119 Target: 5.5.6
    FilesX Xpress Restore 3.5 3.5.165 through 3.5.802 Not planned

    Issue 5. IC64414
    Tivoli Storage Manager FastBack does not support protecting LUNs greater than 2 TB.

    Who is affected:
    All Tivoli Storage Manager FastBack and FilesX Xpress Restore customers backing up LUNs greater than 2 TB.

    written by Bosse

    Jun 09

    Managing the DB2 LOCKLIST Configuration Parameter with Tivoli Storage Manager

    DB LOG, Info, Kommands Comments Off on Managing the DB2 LOCKLIST Configuration Parameter with Tivoli Storage Manager
    Question
    How can the LockList configuration parameter be adjusted to minimize the potential for DB2 deadlocks in a Tivoli Storage Manager environment?
     
     
    Cause
    If the DB2 LOCKLIST parameter is managed incorrectly, it may cause deadlocks to be returned to the Tivoli Storage Manager application for insert, delete and update requests.
     
     
    Answer
    DB2 LOCKLIST PARAMETERThe DB2 LOCKLIST parameter indicates the amount of storage that is allocated within the Database Heap to store lock information. There is one LockList per database and it contains the locks held by all applications, or in this case Tivoli Storage Manager Server transactions, concurrently connected to the database. Locks are stored and manipulated by DB2 in the form of a request block which consumes 40 bytes of memory on 32-bit platforms or 64 bytes on 64-bit systems. By default, DB2 manages the LockList size automatically and increases or decreases the total LockList allocation based on current activity. To determine the current value, issue the following command:

    db2 “get db cfg for <db name>”

    The LockList is comprised of memory allocated as 4K pages. A LOCKLIST parameter value of 10000 (4KB pages) is equivalent to 40,960,000bytes (about 39MB) of memory allotted to the LockList from the Database Heap. A single lock request may require up to 128 bytes out of the LockList heap as one request block is used for the lock descriptor and the second block is used to associate the Tivoli Storage Manager server transaction with the resource being locked. If the lock resource has already been requested then only one request block is required for future transactions requesting that lock resource.

    IMPACT TO THE TIVOLI STORAGE MANAGER SERVER

    The proper management of the DB2 LockList is crucial to prevent deadlocks within the Tivoli Storage Manager server. When the server is under average workload and the amount of concurrent activity is not driving large spikes of lock requests, the DB2 automatic handling of the LockList works well for the Tivoli Storage Manager server. However, when the amount of concurrent data movement activity is high, the inherent spikes to the DB2 LockList can cause lock escalations which will ultimately result in deadlocks within the server.

    The best case scenario is that the Tivoli Storage Manager server will re-drive the request and the subsequent operation will not fail due to the deadlock. Most Tivoli Storage Manager server operations effectively recover from this but in the case where a lot of data had been moved, deleted, or updated, the time required to process the data a second, or even third time can result in severe performance degradation on the Tivoli Storage Manager server. The worst case scenario is that the operation cannot be retried and the entire operation fails.

    If the amount of concurrent data being moved exceeds 500GB at any given time, it is recommended that the DB2 LOCKLIST parameter be adjusted as explained below. If the Tivoli Storage Manager server is involved with deduplicating large files either from the client, or server, properly tuning the LockList manually is extremely critical as large file deduplication inherently drives the number of rows needing to be managed by DB2 very high. This is because a large file is managed in many small pieces which result in many row locks within the DB2 LockList.

    The following Tivoli Storage Manager server messages are issued when a transaction is being rolled back due to a deadlock within DB2.
    ANR0159E dbieval.c(863): Database deadlock detected on XX:X.
    ANR0162W Supplemental database diagnostic information:
    -X:XXXXX:-XXX ([IBM][CLI Driver][DB2/XXXXX] SQL0911N
    The current transaction has been rolled back because of a
    deadlock or timeout. Reason code “2”. SQLSTATE=40001).    

    TUNING THE DB2 LOCKLIST

    To choose a LOCKLIST parameter value that will minimize the amount of deadlocks that may occur within a Tivoli Storage Manager server environment, the maximum amount of data that can be moved, or managed, within the Tivoli Storage Manager server at any given time must be known or at least approximated with a fair amount of precision. .

    Tuning Best Practice: Increase the DB2 LOCKLIST value by twice the amount of anticipated workload so that there are no unexpected failures during daily and nightly operations.

    It is important to note that increasing the DB2 LOCKLIST parameter value has a direct effect on the amount of memory that is required within the instance memory region. Increasing the parameter should be done with the understanding of what the potential memory implications will be on the system. The following information and examples can be used to tune the DB2 LOCKLIST parameter to an appropriate value based on the Tivoli Storage Manager server environment and workload:

    KEY FORMULA FOR DB2 LOCKLIST ADJUSTMENTSConcurrent data movement

    500GB = 2,500,000 locks = 122000 LOCKLIST

    1TB = 5,000,000 locks = 244000 LOCKLIST

    5TB = 25,000,000 locks = 1220000 LOCKLIST

    MEMORY REQUIREMENTS FOR LOCKLIST

    122000 LOCKLIST = 499MB (122000 X 4096)

    244000 LOCKLIST = 1GB (244000 X 4096)

    1220000 LOCKLIST = 4.9 GB (1220000 X 4096)

    Example #1

    100 Tivoli Storage Manager clients store 1TB of data in a 4 hour nightly window

    Migration has the ability to move 1TB of data in the same 4 hour window

    Total concurrent data movement – 2TB

    DB2 LOCKLIST recommendation – 588000

    Additional impact to system memory (potential) – 2.4 GB

    Example #2

    Migration has the ability to move up to 1TB of data in an 8 hour window

    Reclamation can run in the same window and process up to 2TB of data

    Expiration runs in the same window and can process up to 10 Million files which represent 500GB of data

    Total concurrent data movement/management – 3.5 TB

    DB2 LOCKLIST recommendation – 954000

    Additional impact to system memory (potential) – 3.9GB

    UPDATING THE DB2 LOCKLIST PARAMETERThe following command can be used to update the LOCKLIST parameter:

    db2 “update db cfg for <db name> using LOCKLIST XXXXXXXX”

    XXXXXXXXX = LOCKLIST value

    The new value can be verified by issuing the following command:

    db2 “get db cfg for <db name>”

    NOTE: As a result of updating the DB2 LOCKLIST parameter the MAXLOCKS parameter will be set to manual as well. The MAXLOCKS parameter controls what percentage of the LockList that a single transaction can own at any given time. Please ensure this value is set from 95-100. If it is not in this range, the parameter can be updated with the following command:

    db2 “update db cfg for <db name> using maxlocks 97 “

    written by Bosse