Dec 27

IBM Spectrum Protect™ Backup-Archive Client 8.1.4 APARs and 8.1.4.x APARs

Clients Comments Off on IBM Spectrum Protect™ Backup-Archive Client 8.1.4 APARs and 8.1.4.x APARs

Fix Pack 8.1.4

APAR Platforms fixed Description
IT22806 All Unix/Linux 8.1.2 CLIENT’S LANFREE BACK UP FAILS WITH ANS1235E WHEN  THE NODE HAS VALIDATEPROTOCOL SET ALL.
IT22707 All Windows ANS5250E ENCOUNTERED DURING ‘RESTORE SYSTEMSTATE’ IN HARDLINKSWRITE
IT22689 All Platforms UPGRADING BOTH CLIENT AND SERVER TO EITHER 718 OR 812 MAY RESULT IN SSL INITIALIZATION FAILURE WHEN USING MD5 TYPE CERTIFICATES
IT22672 All Unix/Linux ANS1068E ERROR FOR BACKUP IMAGE OF FILESYSTEM CREATED ON DEVICE-MAPPER MULTIPATH DEVICE
IT22660 Windows x64 Hyper-v backup vm with added vhdx can not be restored
IT22556 All Platforms ANS0361I ANR0480W ANR8218W WHEN USING PERFMONTCPSERVERADDRESS
IT22485 All Unix/Linux AUTOMATIC DEPLOYMENT OF BACKUP-ARCHIVE CLIENT MIGHT FAIL ON TARGET MACHINES CONFIGURED FOR SSL/TLS COMMUNICATION
IT22380 All Windows ANS1071E MESSAGE SHOULD REPORT VOLUME MOUNT POINT NAME INSTEAD OF ‘(DRIVE NOT AVAILABLE)’.
IT22377 All AIX
All Linux
UNEXPECTED PATHS FOR FILE(S) IN DSMERROR.LOG FOR FILESET SNAPSHOT BASED BACKUP
IT22374 All Platforms DSMC Q BA QUERYSUMMARY INCORRECT FOR LARGE AVG. FILE SIZE
IT22245 Linux x86
Windows x64
DSMC.EXE MAY CRASH WHEN EXECUTING BACKUP VM WITH IFINCREMENTAL MODE
IT22157 All Platforms SNAPDIFF DOCUMENTATION NEEDS CLARIFICATION FOR IBM SPECTRUM PROTECT BACKUP-ARCHIVE CLIENT PROCESSING OPTION
IT22038 All Platforms CLIENT MAY GIVE “RC 0” WHEN A FILE COULD NOT BE DELETED DURING ARCHIVE PROCESSING WITH “-DELETEFILES” OPTION
IT21994 All Unix/Linux AFTER AN INSTALL FAILURE WRONG CODE IS RECORDED IN THE LOGS TO THE SP SERVER
IT21991 All Platforms EXPECT ANS5294E ERROR MESSAGE, INSTEAD  ANS8007E WHEN TRY TO CONNECT TO 8.1.2 SERVER AS NON-AUTHORIZED USER.
IT21983 All Windows IBM SPECTRUM PROTECT CLIENT CAN CRASH ON WINDOWS IF MICROSOFT SYSTEM PARTITION HAS A PATH NAME EQUAL OR GREATHER THAN 49 CHARS
IT21873 All Unix/Linux DSMADMC MIGHT CRASH WHEN A COMMAND IS SUBMITTED WITH DISPLAYMODE SET TO TABULAR
IT21657 All Windows ANS9999E MESSAGE WITH FILE ACCESS ERROR RETURN CODE 1359 CAUSES AN ANS1999E AND STOPS THE BACKUP
IT21639 All AIX
All Linux
CLIENT INCORRECTLY PROCESSES FILELIST OF IBM SPECTRUM SCALE SNAPSHOTS WITH NESTED MOUNTPOINTS.
IT21512 All Windows DSMCAD.EXE CAN HANG TRYING TO START DSMSVC.EXE DUE TO A HANDLE LEAK
IT21322 Mac AFTER UPGRADE TO 7.1.6.5, THE NEXT INCREMENTAL BACKUP WILL UPDATE ATTRIBUTES ON THE SERVER FOR OBJECTS WITH NO CHANGES.
IT21310 Mac RESTORE OF FILES WITH A SERIES OF NULL VALUES MAY BE CORRUPTED.
IT21291 All Windows AUTHORITATIVE RESTORE OF A CLUSTER NODE USING “RESTORE SYSTEMSTATE CLUSTERDB” COMMAND FAILS WITH ANS5189E
IT21200 All Windows BACKUP OF SYSTEMSTATE CAN ERROR WITH ANS1228E/ANS4987E FOR ‘BCD’  OBJECT IF ‘BCD’ IS IN LOWERCASE
IT21172 All Platforms DEDUBLICATION CACHE NOT RESTORED AUTOMATICALLY IN CASE OF FILE INTEGRITY ERROR
IT21123 All Platforms DSMADMC TABULAR OUTPUT IS NOT PROPERLY ALIGNED WITHIN COLUMNS AND HYPHENATION IS INCORRECT
IT21089 Linux x86 “ANS1592E FAILED TO INITIALIZE SSL PROTOCOL” USING 8.1.0.2 API CLIENT FOR X86_64 LINUX
IT21059 All Unix/Linux A NON-ROOT USER PERFORMING A BACKUP/ARCHIVE OPERATION ON UNIX PLATFORM, CONFIGURED FOR AUTOMATED FAILOVER, RECEIVES ANS1035S
IT21056 All Windows DUPLICATE ANS1899I MESSAGES ARE ISSUED DURING SYSTEM STATE BACKUP
IT21052 Linux zSeries INSTALL OF THE 7.1.4 AND 7.1.6 CLIENTS FOR RHEL 5 ON ZLINUX FAILS LIBRARY DEPENDENCIES.
IT21045 All Windows DSMAGENT CRASHES WHEN PERFORMING VSS BACKUP AGAINST A HIGH NUMBER OF MICROSOFT SQL DATABASE
IT20999 All Linux
All Windows
Solaris
PROCESSOR MODEL IS INCORRECTLY REPORTED BY THE CLIENT FOR INTEL CPUS WITH A VERSION NUMBER
IT20371 All Platforms ABSTRACT: IBM SPECTRUM PROTECT CLIENT MAY HANG DURING PROCESS MGMTCLASS
IT20103 All Windows CLIENT AUTO DEPLOY FAILS DURING THE VC++ PORTION OF THE INSTALLATION
IT19623 All Windows “UNABLE TO OPEN FILE ‘DSMMSINFO.TXT'” MESSAGE WHEN RUNNING “DSMC  Q SYSTEMINFO” ON A “WINDOWS 2016 SERVER CORE”
IT17338 All Platforms CLIENT STOPS A RESTORE OPERATION IF AN “ANS1154E” ERROR IS
ENCOUNTERED IN CLASSIC RESTORE MODE.

written by Bosse

Feb 23

Modified Instructions for Complete Restores of Windows Systems with the TSM Client: Bare Metal Restore (BMR), System State Restore, Windows System Object Restore

Windows VSS Comments Off on Modified Instructions for Complete Restores of Windows Systems with the TSM Client: Bare Metal Restore (BMR), System State Restore, Windows System Object Restore

Technote (troubleshooting)

Problem(Abstract)

The following article provides guidance for complete system restores of Windows 2003, 2003 R2, Vista, 2008, 2008 R2, and Windows 7 systems using the TSM client and system state restore. Systems running Microsoft Windows 8, Windows 2012, and Windows 2012 R2 are also supported for EFI systems. The procedure applies to the restore technique where you are restoring over a running operating system. These procedures should only be followed after less severe recovery techniques such as Microsoft System Restore have been attempted.

Cause

Note: For Windows 2008, 2008 R2, Vista, Windows 7, 2012, 2012 R2, and Windows 8 there is a Automated System Recovery (ASR) support capability available with 6.3.2 and newer client levels. The ASR restore approach is preferred over the approach covered in this document for non-EFI systems. More information on the ASR approach is available via the following links:

A number of fixes have recently been introduced in the TSM client which impact the success of complete system restores.

  • The following or newer client levels for the releases in service are recommended:
    • 6.3.2.4, 6.4.3.x or 7.1.x when using TSM server 6.3.x

Note that not all Windows operating systems discussed below are supported on all TSM client releases currently in service. See the following link for supported levels: Windows Client Requirements

Resolving the problem

Preparation:
In order to perform a complete system restore, a complete backup is needed. The backup must include a complete backup of the system drive, and a backup of the system state. You may also need to backup additional drives besides the system drive if they exist on your system. Generally, this should include any drive containing critical user data or application program files. The following points should be considered:

  1. A scheduled backup of the default all-local domain will include both the system drive and system state.
  2. Care must be taken not to exclude required application files from the system drive backup. The sample options file in the config directory lists suggested include/exclude rules which are known not to interfere with system recovery. The sample options files can be found in the normal installation path. For example, c:\program files\tivoli\tsm\config\dsm.smp.
  3. A number of files on the system drive are automatically excluded from backup based on operating system controls. The “query inclexcl” command can be used to view the rules which will affect which files are automatically excluded during backup. Files which are under Windows system file protection can only be backed up as part of the system and boot files component of system state. They are automatically excluded from normal system drive backup processing.
  4. System recovery time can be greatly reduced by maintaining a volume-level image of the base Windows installation.

Restore Procedure:
The following restore procedure is required when you are restoring your complete operating system over a running operating system. These procedures are not required if you are restoring with Automated System Recovery (ASR). See note #5 for additional details related to ASR.

Preparation steps:

  1. It is strongly recommended that you restore to identical hardware to which the backup was taken from. In virtualized environments there often subtle differences between the original system and the restore target which can cause problems. Here are some common ones to avoid:
    1. Different code levels for the hypervisor.
    2. Different virtual hardware levels.
    3. Different virtual devices assigned to the virtual machine. For example, a different type of virtual disk controller or network adapters, or changes in the number of these devices.
  2. In order to restore, you need a base operating system running with the TSM client installed, and connectivity to the TSM server.
  3. Windows must be installed in the same directory at which it was installed at the time of backup (c:\Windows for example.) The system drive file system must be formatted in the same file system type that existed at the time of backup. For systems previously upgraded from Windows NT4.0, you may have difficulty installing the base OS in the original directory. See notes below for more information.
  4. The system name must be set to match the system name at the time of backup. Unless this is set, the system state component cannot be restored.
  5. If you are recovering a domain controller, do not promote the base operating system to a domain controller prior to running the restore.
  6. Apply the same Windows service pack to the base operating system which was installed at the time of backup. In addition, on Windows 2003 servers, the VSS hotfixes identified in KB940349 and KB934016 need to be installed following any service pack installations.
  7. Partition and format any additional volumes required for recovering the systemstate or additional drives. For example, if you are restoring a domain controller with NTDS files stored on a drive other than C:, you will need to create the additional drives before proceeding with the restore. The new drives need to be of equal or greater capacity, formatted with the same file system type, and mapped to the same drive letter or directory that was used at the time of backup.
  8. Ensure that the Windows default administrative shares exist for all of the drives to be restored. Issue the following Windows command to check this:
    > net share
  9. For restores from a TSM server, you will need a working network connection. Even with local backupset restores, problems have been encountered resolving UNC names on systems where there are no active network connections, so you should have at least one active network connection before attempting the restore.
  10. For Windows 2003 domain controller restores, the option FRSPRIMARYRESTORE can be set to YES prior to performing the systemstate restore. Recovering the first domain controller in a domain is one example where using the option to force an authoritative FRS restore is required. An authoritative SYSVOL restore is not possible when using ASR.
    Note: Performing an authoritative SYSVOL restore is not supported for Windows versions newer than Windows 2003. See APAR IC79919 for additional information.
  11. For Windows 7 and Windows 2008 R2 systems, use regedit to confirm that the registry subkey HKEY_LOCAL_MACHINE->COMPONENTS exists prior to restoring the system state. See APAR IC65386 for more details.

Restore steps (see the additional information section for notes on using the Graphical Users Interfaces):

  1. Restore the system drive. Ignore the request to reboot at the end of the restore and proceed to the next step! Repeat this restore step for all other drives that exist on your system.> dsmc restore c:\* -sub=yes -rep=all
  2. Restore the system state. On Windows 2003, the option frsprimaryrestore yes can be added to the client option file prior to running the following commands if an authoritative sysvol restore for a domain controller is required. If you are restoring a Windows 2008 server running failover cluster services you may need to add the keyword bootable to the restore systemstate command. See below for more information on restoring clustered systems.> dsmc restore systemstate
  3. Reboot

The following example shows a complete sequence of commands for restoring a Windows system using environment variables to avoid fixed drive letters and paths.

> dsmc restore %systemdrive%\* -sub=yes -rep=all
> dsmc restore systemstate

Additional Information
1. There are four files under system file protection which cannot be restored due to a Microsoft Windows limitation with replace on reboot. These files are: ntdll.dll, smss.exe, dtcsetup.exe, and ctl3dv2.dll. If you are restoring over a base Windows image which contains down-level versions of these files versus those contained in your backup image, you may experience system problems following the restore including:
2. When is it necessary to use “Directory Services Restore Mode” (DSRM)? The normal complete system recovery procedure for a domain controller does not require DSRM. The use of DSRM is only required when a server is already active as a domain controller, and recovery of NTDS is prevented when the Active directory services are active. When performing a complete system recovery, do not promote your newly installed base OS to a domain controller prior to performing the restore. The system should automatically become a functioning domain controller as a result of the restore. Alternatively, DSRM is required if your server is already operating as a domain controller, and restore of the active directory is needed to resolve an issue such as accidental deletion of active directory objects. In this scenario, booting to DSRM prevents the NTDS services from starting, allowing a TSM restore of system state including NTDS.

3. Following a domain controller recovery, you may see errors in the Windows event viewer for file replication services which indicate that the server is prevented from becoming a domain controller due to problems with the SYSVOL share. In normal cases, this message will eventually be followed by another message indicating that SYSVOL has been shared and is no longer preventing the server from becoming a domain controller. If this does not happen, manual repairs to the SYSVOL structure may be required. In many cases, the SYSVOL directory structure can be repaired, and FRS will replicate in the correct contents of the SYSVOL. Microsoft article KB315457 provides details on how to rebuild the SYSVOL tree including the junction points which are required before a system can be returned to a domain controller.

http://support.microsoft.com/kb/315457

4. In some situations, special steps are required to force Windows to install into a non-default directory when installing your base operating system. For example, a system which is upgraded from Windows 2000 to Windows 2003 will maintain the operating system files in C:\WINNT. When installing a base Windows 2003 operating system for recovery purposes, Windows will force the installation into the C:\WINDOWS directory by default. A successful restore will not be possible unless the base Windows 2003 operating is forced to install into the C:\WINNT directory instead of C:\WINDOWS. Microsoft article KB235478 provides instructions on how to force Windows to install into a non-default directory.

http://support.microsoft.com/kb/235478

5. An additional recovery feature known as Automated System Recovery (ASR) is available with the TSM client. With ASR you will not be required to perform many of the steps described in this document, including the pre-restore of the SFP catalogs. The TSM restores performed during ASR occur while Windows system file protection is not running. See the links at the beginning of this document for links to additional information on ASR.

6. The procedures listed in this article are not recommended for recovering an operating system to dissimilar hardware. However, in situations where there is no alternative, two methods have provided limited success repairing boot problems following restores to dissimilar hardware. The first technique involves retaining a copy of critical hardware specific files after installing the base operating system and copying these files back after performing the restore, but before rebooting the system. See the following Microsoft article for more discussion on this technique:

http://support.microsoft.com/kb/Q249694

The second technique uses the Windows installation CD repair facility to repair the restored operating system which is failing to boot. This procedure is some times referred to as “upgrade in-place” or “repair installation.” See the following Microsoft articles for more information on this technique:

http://support.microsoft.com/kb/315341

http://support.microsoft.com/kb/816579

7. Tips for recovering NTDS or SYSVOL components to a new location without restoring the entire systemstate.

In certain circumstances, you may desire to restore NTDS or SYSVOL files for a domain controller to an alternate location, and then use Microsoft utilities to recover from these restored files. Tivoli does not provide support for these recovery techniques, but provides these commands for users who have a requirement for recovery of NTDS and/or SYSVOL without a complete systemstate recovery, and have knowledge of the procedures necessary for recovering from the files which have been restored to an alternate location.

WARNING: these restore commands may create junctions in the restore target directory that point back to critical directories on the running system. Do not delete the temporary restore destination using the Windows explorer interface since it is known to also delete the contents at the target of junctions. Instead, we recommend using the Windows rmdir command to remove the temporary directory.

rest "{SERV1\SystemState\NULL\System State\SystemState}\\serv1\e$|\ntds\*" e:\ntdsrest\ -sub=y

Your pathnames for where NTDS and SYSVOL may vary requiring adjustment to these commands. If you are having trouble locating the correct path, you can search for the files with a command like the following:dsmc q b "{SERV1\SystemState\NULL\System State\SystemState}\ntds.dit" -sub=y

8. A systemstate restore may fail with the message ANS1056E Share/network path cannot be resolved. This failure may be caused by the absence of the default administrative shares for drives which need to be accessed during the systemstate restore. You can determine if you have this problem by issuing the Windows command net share to ensure the shares are listed for all drives. In most cases rebooting will restore the missing shares. Alternatively, stopping and starting the Windows server service may also restore these shares.

9. A systemstate restore may fail with the error message ANS1949E Microsoft volume shadow copy snapshot initialization failed. See the following technote for a possible solution to this problem:
http://www.ibm.com/support/docview.wss?&uid=swg21385864

10. Restores of Windows 2008 systems running failover cluster services require a modification to the restore commands described above. Without this modification, the restore systemstate command may fail with the
error:
ANS5211E The cluster service is offline. The cluster service must be online to perform an authoritative cluster database restore operation.

This error is encountered because the clusters services are not running as part of a base Windows operating system. In most recovery cases, other nodes in the cluster are still running, so there is no need to restore the cluster database since it will automatically copy back from the other nodes. In rarer cases, an authoritative restore of the cluster database is needed when other cluster nodes are not present or the cluster database has been corrupted on all nodes.

The non-authoritative restore sequence uses the bootable subkey to avoid ANS5211E:

dsmc restore c:\* -sub=yes -rep=all
dsmc restore systemstate bootable
reboot

Authoritative restore sequence :

dsmc restore c:\* -sub=yes -rep=all
dsmc restore systemstate bootable
reboot
dsmc restore systemstate clusterdb

11. The restore procedures described in this document can also be performed using the graphical user interface with the exception of the steps for performing a pre-restore of the Windows system file protection catalogs.

To restore the system drive:
a) Click “Restore”
b) Expand “File Level”
c) Select the entire drive representing the system drive, for example, \\tsmbldx861\c$ (C:)

d) Click the “Options” button, and select the options for files which already exist “Replace” and “Replace files even if read-only/locked”, then click OK

e) Click “Restore”, and select “Original location”, then click “Restore” again

f) Ignore the request to reboot at the completion of this restore and proceed to the systemstate restore.

To restore the system state:
a) Click “Restore”
b) Select the object “SystemState”, and click “Restore”

12. The following are links to additional information on TSM topics useful for Windows system recovery.

Best practices instructions for a new ASR system recovery approach:

White paper titled “Tivoli Storage Manager Recovery Techniques Using Windows Preinstallation Environment (Windows PE)”
http://www.ibm.com/support/docview.wss?uid=swg27005028

Technote explaining restore location of the Windows event log files for Windows 2003
http://www.ibm.com/support/docview.wss?uid=swg21223228

written by Bosse

Apr 05

Auditing and repairing a deduplicated file storage pool

TSM Server Comments Off on Auditing and repairing a deduplicated file storage pool

Technote (troubleshooting)

Problem(Abstract)

Under some circumstances, an audit of a deduplicated storage pool might be necessary. Two utilities, the dedupAuditTool.pl and dedupRepairTool.pl scripts, are now available. These can be used to audit the deduplication tables to ensure referential integrity, proper chunk linkage, and to clean up 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 by using the “DELETE VOLUME VolumeName DISCARDDATA=YES” command. This command will remove data chunks from the database and media regardless of dependencies within the catalog, which will create invalidated links. As a result, you must follow the DELETE VOLUME DISCARDDATA=YES command with an audit against the ANR4895E message to cleanup the invalidated links. Until the audit is run, you will see ANR4895E or ANR1162W messages in the activity log that indicates that there are invalidated links. See the “Recovering from lost or damaged FILE volumes in deduplicated storage pool” technote for in-depth cleanup instructions for this situation.

Another potential cause of invalidated link and referential integrity errors is from DB2® table damage that can occur from a hardware failure. In this case, you can use the DB2DART utility to restore structural integrity. Then use the dedupAuditTool perl script attached to this document to identify referential integrity problems.

The following list includes APARs that describe how links can be invalidated during data movement operations:

IC90390
IC96993

To prevent the problems which are documented in these APARs from occurring in your deduplication environment, ensure you are using server version 6.3.5.100 or later.

Environment

This applies to IBM Spectrum Protect™ servers with a DEVType=FILE storage pool that has deduplicated data. The data can be deduplicated either by client-side or server-side (identify processing) deduplication.

Beginning with Version 7.1.3, IBM® Tivoli® Storage Manager is now IBM Spectrum Protect. Some applications such as the software fulfillment systems and IBM License Metric Tool use the new product name. However, the software and its product documentation continue to use the Tivoli Storage Manager product name. To learn more about the rebranding transition, see technote 1963634.

Diagnosing the problem

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

Resolving the problem

Overview

Note: The dedupRepairTool.pl script currently does not support container storage pools. If you are running server version 7.1.3 or later and have configured container storage pools, do not run the dedupRepairTool.pl script against any storage pools on such servers.

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.

It is important to note that the dedupAuditTool.pl is not intended to be an overall health check for deduplication enabled storage pools. You should only run the tool if you have experienced one of the symptoms described in this article.

The dedupAuditTool.pl is a perl script, which performs the analysis phase. The analysis phase is designed to accept environment and symptom information from the user. With this information, the tool interrogates the various IBM Spectrum Protect tables that are associated with the given symptom that was specified. At then end of the analysis phase, an audit report is generated. Send this report to IBM support for analysis. If the analysis determines that the problems identified in the report need correcting, they will provide you another tool, dedupRepairTool.pl, to perform 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 IBM Spectrum Protect server resides. Because the Perl scripts interrogate the DB2 database directly, they must be run from this system. To obtain code for the Perl installation, go to http://www.perl.org
  • The tools 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 scripts are being executed and the directory where the client is installed (for example, /opt/tivoli/tsm/client/ba/bin64).
  • The tools require access to both DB2 and IBM Spectrum Protect by using the dsmadmc and DB2 CLIs.
  • On Windows systems, initialize the DB2 command line environment prior to executing the scripts by issuing “db2cmd” from a Windows administrative command prompt.
  • You must use Perl 5.8.0 or later (A Perl interpreter can be download from – www.perl.org).
  • Different versions of the dedupAuditTool scripts are available depending on which interpreter is available
    – dedupAuditTool.pl (5.10 or later)
    – dedupAuditTool_perl_v580 (5.8.0 – 5.10)
  • The tools are interactive scripts. They do not accept command line parameters.
  • The tools are multi-phase scripts (the dedupAuditTool.pl script does not include the final phase) – Environment Setup, Audit Tool Setup, Audit Analysis and Report Generation, Cleanup of Deduplicated Storage Pool.
  • It may be necessary to run the dedupAuditTool.pl and dedupRepairTool.pl multiple times in order to restore the referential integrity of the database.

How Are The Scripts Executed?:
perl dedupAuditTool.pl
perl dedupRepairTool.pl

Important Usage Notes:

  • An AUDIT VOLUME command should be run against all suspect volume(s) PRIOR to running the script dedupRepairTool.pl in RECOVERY mode. This will ensure that all files currently marked as damaged are validated as truly damaged before they are forcibly deleted.
  • If a DELETE VOLUME DISCARDDATA=YES command has been issued against a volume that is located in a deduplicated storage pool, the dedupRepairTool.pl script should be run immediately afterward with the ANR4895E symptom to resolve all of the invalidated links. Contact IBM support for access to dedupRepairTool.pl.
  • The script should be run only 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.
    – The IBM Spectrum Protect server is at 6.3.5.100 or later.
    – The dedupRepairTool.pl script should only be run against primary storage pools. Do not run the script for repairs against deduplicated copy pools and active data pools. The dedupAuditTool.pl script can be run against these pools, but the CHUNKS_NOT_CATALOGED category in the report it generates may include false positives for active data pools.
    – All data movement and expiration activity for the deduplicated storage pool has been quiesced; refer to the section “Preparation for running script” below for details. If the storage pool is not quiesced, the script may report false-positive results, have or cause the server to have severe performance issues, or cause deadlocks in server operations.
  • 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 that is 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 can run for a long period of time, depending on the size of the database and the deduplicated storage pool.

Audit Phase Options (dedupAuditTool.pl, dedupRepairTool.pl) :
* The deduplication catalog can be analyzed by either auditing a symptom or by processing a
previously generated audit file

Recovery Phase Options (dedupRepairTool.pl only) :
* 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 IBM Spectrum Protect server.
– Restore Only
All invalid data is attempted for restoration from a copy pool.
– Delete Only
All invalid data will be removed from the IBM Spectrum Protect 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.

Preparation for running script

    Before proceeding with the cleanup procedure, perform the following:

    • A current FULL database backup is taken
    • All data movement and deletion activity in the deduplicated Storage pool has been quiesced. This would include the following processes:
        • Expiration
        • Reclamation
        • Migration
        • Move Data
        • Move NodeData
        • Identify Duplicates
        • Backup/Archive
    • To accomplish this add the following options in the server options file and restart the server:
      • NOMIGRRECL
      • EXPINT 0
      • DISABLESCHEDS YES
    • Prevent all processing in the deduplication enabled storage pool by issuing the following commands:
      • DISABLE SESSIONS
      • IDENTIFY DUPLICATES storage_pool_name NUMPROC=0
    • IMPORTANT NOTE: Once you have resolved all issues, reset all options and allow processing to the storage pool to resume, perform the following:
      • Remove the following options you added above:
        • NOMIGRRECL
        • EXPINT 0
        • DISABLESCHEDS YES
      • Restart the server and issue the following command:
        • ENABLE SESSIONS

Script Examples (contains both dedupaudittool.pl and deduprepairtool.pl output)

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
Backup/Archive

– The Tivoli Storage Manager server is at 6.3.5.100 or 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
***********************************************************

Auditing with script

Would you like to see all available symptoms that can be audited? <def: Y>: Y

*********AUDIT SYMPTOMS*********
ANR1165E
ANR1529I
ANR1162W
ALL (INCLUDES EVERYTHING BELOW):
ANR4895E
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 with dedupRepairTool ONLY) RECOVERY OF INVALID LINKS (Using Audit File with dedupRepairTool ONLY)

***********************************************************************
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
Backup/Archive

– The Tivoli Storage Manager server is at 6.3.5.100 or 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
Backup/Archive

– The Tivoli Storage Manager server is at 6.3.5.100 or 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
***********************************************************

Auditing with script

Would you like to see all available symptoms that can be audited? <def: Y>: Y

*********AUDIT SYMPTOMS*********
ANR1165E
ANR1529I
ANR1162W
ALL (INCLUDES EVERYTHING BELOW):
ANR4895E
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 later
dedupAuditTool_v580.pl – Script that requires PERL version 5.8.0 – 5.10

NOTE: It is recommended that dedupAuditTool.pl is used if the 5.10 or later PERL
interpreter is available for the given operating environment.

written by Bosse

Jun 30

TSM for Databases – All Requirement Documents

SQL, TDP Comments Off on TSM for Databases – All Requirement Documents

Version 7.1.2

Version 7.1.2 was announced on April 14, 2015 and will be available for download on April 17, 2015. Information regarding how and where to download 7.1.2 will be available here:
http://www.ibm.com/support/docview.wss?uid=swg24039480 on the download availability date.

—————————————————————-

Version 7.1.1

The version 7.1.1 Fix Pack was announced on September 2, 2014 and will be available for download on September 12, 2014. Information regarding how and where to download 7.1.1 will be available here: http://www.ibm.com/support/docview.wss?uid=swg24038212 on the download availability date.

—————————————————————-
Version 7.1

Version 7.1 was announced on October 29, 2013 and will be available electronically on December 13, 2013.
—————————————————————-

Version 6.4.1

  • Data Protection for Oracle was not updated to the 6.4 level. Please refer to the 6.3.x HW & SW requirements link listed below

—————————————————————-

Version 6.4

Version 6.4 was announced on October 3, 2012 and will be available electronically on November 16, 2012.

—————————————————————-

Version 6.3.1

 

      The V6.3.1 Fix Pack was delivered to the public FTP site on December 18, 2012.

 

      This fix pack includes:

      • APAR fixes
      • Toleration level support for Windows 2012 Server
      • Toleration level support for Microsoft SQL Server 2012.

Note:

    The exploitation of new features available with Windows 2012 Server and Microsoft SQL Server 2012 is available in the Version 6.4 release.

—————————————————————-

Version 6.3

—————————————————————-
Version 5.5.6
TSM for Databases 5.5 has reached end of support via some product offerings. Please refer to the following tech note for additional information: http://www-01.ibm.com/support/docview.wss?uid=swg21665620

 

The V5.5.6 Data Protection for SQL Fix Pack was delivered to the public FTP site on September 5, 2012.

—————————————————————-

Version 5.5.5

TSM for Databases 5.5 has reached end of support via some product offerings. Please refer to the following tech note for additional information: http://www-01.ibm.com/support/docview.wss?uid=swg21665620
The V5.5.5 Data Protection for SQL Fix Pack was delivered to the public FTP site on December 10, 2010.

—————————————————————-

Version 5.5.4

TSM for Databases 5.5 has reached end of support via some product offerings. Please refer to the following tech note for additional information: http://www-01.ibm.com/support/docview.wss?uid=swg21665620

Available: June 4, 2010

Data Protection for Microsoft SQL Server released a V5.5.4 Fix Pack. This document contains the updated V5.5.4 hardware and software requirements.

Changes to DP for SQL 5.5.4:

  • APAR fixes for all platforms
  • Support for SQL backup compression option available with SQL Server 2008
  • Backup & Query performance improvements for Microsoft SQL Server environments that contain a large number of SQL databases
  • Expansion of Instant Restore support from SE target volumes for SVC 5.1

—————————————————————-

Version 5.5.3

TSM for Databases 5.5 has reached end of support via some product offerings. Please refer to the following tech note for additional information: http://www-01.ibm.com/support/docview.wss?uid=swg21665620
TSM for Databases was updated on October 23, 2009 to include the following updated components:

  • Data Protection for SQL V5.5.3

Changes to DP for SQL 5.5.3:

  • APAR fixes for all platforms
  • Support for SVC 4.3

—————————————————————————————–

Version 5.5.2

TSM for Databases 5.5 has reached end of support via some product offerings. Please refer to the following tech note for additional information: http://www-01.ibm.com/support/docview.wss?uid=swg21665620

TSM for Databases was updated on June 12, 2009 to include the following updated components:

    • Data Protection for Oracle V5.5.2

Changes for DP for Oracle 5.5.2:

    • Added Oracle 11g for Windows 2008 support
    • Added Asianux 3.0 support

TSM for Databases was updated on November 26, 2008 to include the following updated components:

    • DP SQL V5.5.2 PTF

—————————————————————————–

Version 5.5.1

TSM for Databases 5.5 has reached end of support via some product offerings. Please refer to the following tech note for additional information: http://www-01.ibm.com/support/docview.wss?uid=swg21665620
TSM for Databases was updated on July 3, 2008 to include the following updated components:

  • Data Protection for Microsoft SQL V5.5.1

 

Changes for DP for SQL 5.5.1:

 

    Added Windows 2008 support

 

The initial release of TSM for Databases V5.5.1 (available) April 17, 2008) contained:

  • Data Protection for Oracle V5.5.1
  • Data Protection for Microsoft SQL V5.5.0.

 

Changes for DP for Oracle 5.5.1:

 

      Added Oracle 11g support

Added support for the following OS / platforms:

 

        RHEL 4 on Linux Itanium RHEL 5 on Linux Itanium, Linux x86_64, and Linux x86

SLES 9 on Linux Itanium SLES 10 on Linux Itanium, POWER, and z64

HP11iv3 for PA-RISC and IA64 AIX 6.1

Added:

  • An option to Indicate whether backup objects are encrypted
  • Logging throughput statistics
  • New product installer

 

—————————————————————————–

Version 5.5.0

TSM for Databases 5.5 has reached end of support via some product offerings. Please refer to the following tech note for additional information: http://www-01.ibm.com/support/docview.wss?uid=swg21665620

 

TSM for Databases V5.5.0 contains:

  • Data Protection for Microsoft SQL V5.5.0
  • Data Protection for Oracle V5.4.1

The hardware and software support requirements for Data Protection for Microsoft SQL have been updated to reflect the Version 5.5.0 release.

Changes: To see a list of enhancements for this release, please refer to US Announcement Letter 207-290. This package is on Passport Advantage.

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

May 23

Node Replication failed with Reason Code: XXX

Node Replication Comments Off on Node Replication failed with Reason Code: XXX

Problem(Abstract)

Tivoli Storage Manager Node replication can fail with a reason code or a Global Return Code (GRC) number. This technote provides a description of each GRC value.

Cause

Tivoli Storage Manager use a Global Return Code to document the errors received during various operations. These return code are unique for Server and storage agent operations. Depending on the error condition, the GRC code can be logged to the server activity log along with an ANR message.

Environment

Tivoli Storage Manager Server V6 and V7

Diagnosing the problem

Example of an ANR message with GRC :


ANR1936E Replication of BACKUP data for file space fs1 on node NODE1 failed with reason: Reason code 1020.

In above example, the reason code 1020 translates to GRC_LOCK_CONFLIC

 

Resolving the problem

Below are a list of GRC codes can be received during node replication.

Return codes for replication only:

GRC_NO_REPL_WORK_FOUND                  2001
GRC_REPLICATION_UNAVAIL_SRC             2090
GRC_REPLICATION_UNAVAIL_TGT             2091
GRC_REPLICATION_NODE_DISABLED           2092
GRC_REPLICATION_RULE_DISABLED           2093
GRC_REPLICATION_FS_DISABLED             2094
GRC_REPLICATION_MODE_INCOMPAT           2095
GRC_OPERATION_IN_PROGRESS               2096
GRC_SKIP_REPL_FOR_PREVIEW               2097
GRC_SKIP_UPDATE_FOR_PREVIEW             2098
GRC_REPLICATION_TGT_SYNC_NODE_UNDEF     2099
GRC_REPL_NODE_READ_ONLY                 2100
GRC_REPL_SRV_DELETE_INPROGRESS          2101

Return codes common to all components:

GRC_NO_SPACE                            1001
GRC_NO_MEMORY                           1012
GRC_DEADLOCK_DETECTED                   1014
GRC_NO_LOG_SPACE                        1015
GRC_NO_DB_SPACE                         1016
GRC_DEADLOCK_EXISTS                     1018
GRC_CONDITIONAL_LOCK_FAILED             1019
GRC_LOCK_CONFLICT                       1020
GRC_LOCK_CONFLICT_RETRY                 1021
GRC_LOCK_NOT_GRANTED                    1022
GRC_LOCK_REQ_ABORTED                    1023
GRC_NO_THREAD                           1024
GRC_TXN_FAILED                          1030
GRC_TXN_ABORTED                         1031
GRC_RETRY_TXN                           1032
GRC_INSUFFICIENT_AUTHORITY              1040
GRC_CANCEL_PENDING                      1050
GRC_CANCEL_FAILED                       1051
GRC_CANCELED                            1052
GRC_SYNTAX_ERROR                        1060
GRC_INVALID_USE                         1061
GRC_NOT_PROCESSED                       1062
GRC_BUF_TOO_SMALL                       1063
GRC_OBJECT_NOT_FOUND                    1100
GRC_BITFILE_NOT_FOUND                   1101
GRC_VOLUME_NOT_FOUND                    1102
GRC_LIBRARY_NOT_FOUND                   1103
GRC_DRIVE_NOT_FOUND                     1104
GRC_PATH_NOT_FOUND                      1105
GRC_NODE_NOT_FOUND                      1106
GRC_FILESPACE_NOT_FOUND                 1107
GRC_VFS_NOT_FOUND                       1108
GRC_OBJSET_NOT_FOUND                    1109
GRC_DOMAIN_NOT_FOUND                    1110
GRC_POLICYSET_NOT_FOUND                 1111
GRC_MGMTCLASS_NOT_FOUND                 1112
GRC_COPYGROUP_NOT_FOUND                 1113
GRC_KEY_NOT_FOUND                       1114
GRC_TABLE_NOT_FOUND                     1115
GRC_ITEM_NOT_FOUND                      1116
GRC_SERVER_NOT_FOUND                    1117
GRC_ADMIN_NOT_FOUND                     1118
GRC_NODEGROUP_NOT_FOUND                 1119
GRC_POLICY_NOT_FOUND                    1120
GRC_NO_DEFAULT_MGMTCLASS                1121
GRC_NODE_NOT_IN_DOMAIN                  1122
GRC_STGPOOL_NOT_FOUND                   1123
GRC_SCRIPT_UNDEFINED                    1124
GRC_OPTSET_NOT_DEFINED                  1125
GRC_AUTHRULE_NOT_DEFINED                1126
GRC_VFS_MAPPING_EXISTS                  1127
GRC_SESSION_NOT_FOUND                   1128
GRC_CLASS_NOT_FOUND                     1129
GRC_CLASSNAME_NOT_DEFINED               1130
GRC_NO_DATAMOVER                        1131
GRC_DB_ALIAS_NOT_FOUND                  1132
GRC_DUPLICATE_OBJECT                    1200
GRC_KEY_EXISTS                          1202
GRC_ITEM_EXISTS                         1203
GRC_NODE_ALREADY_DEFINED                1204
GRC_ADMIN_ALREADY_DEFINED               1205
GRC_OPTSET_ALREADY_DEFINED              1206
GRC_NODEGROUP_ALREADY_DEFINED           1207
GRC_FS_ALREADY_DEFINED                  1208
GRC_AUTHRULE_ALREADY_DEFINED            1209
GRC_VFS_ALREADY_DEFINED                 1210
GRC_CLASSNAME_ALREADY_DEFINED           1211
GRC_VOLUME_ALREADY_DEFINED              1212
GRC_THREAD_ALREADY_RUNNING              1213
GRC_LDAP_ERROR                          1220
GRC_PASSWORD_TOO_SHORT                  1221
GRC_PASSWORD_TOO_YOUNG                  1222
GRC_PASSWORD_IN_HISTORY                 1223
GRC_PASSWORD_NOT_COMPLEX                1224
GRC_LOCKED_LDAP                         1225
GRC_PASSWORD_RESET                      1226

written by Bosse

May 21

VMCLI node connects every 20 minutes to the Tivoli Storage Manager server

VE Comments Off on VMCLI node connects every 20 minutes to the Tivoli Storage Manager server

Problem(Abstract)

In an environment configured with Tivoli Storage Manager for Virtual Environments software, the Tivoli Storage Manager server shows a client connection every 20 minutes for the Data Protection for VMware VMCLI node.

Resolving the problem

By default, reconciliation operations run every 20 minutes on the Derby database to delete metadata for backups that are no longer available. This action ensures that the Derby database remains synchronized with the Data Protection for VMware repository. When reconciliation runs, the VMCLI node connects to the Tivoli Storage Manager server.

The interval between reconciliation operations on the Derby database with Data Protection for VMware is specified by the VMCLI_RECON_INTERVAL_TSM parameter, which is one of the Data Protection for VMware command-line interface profile parameters. The default value for the parameter is 1200 seconds (20 minutes).

You can adjust the value of the parameter to reduce the frequency of connections made by the VMCLI node. For example, to have the VMCLI node connect to the Tivoli Storage Manager server once a day use the following parameter :

VMCLI_RECON_INTERVAL_TSM 86400

Note that the VMCLI node also establishes a connection to the Tivoli Storage Manager server when the Tivoli Storage Manager for VMware UI is started, regardless of the value set with the VMCLI_RECON_INTERVAL_TSM parameter.

written by Bosse

Feb 03

Understanding metadata for TSM DP for VMware VM backups

VE Comments Off on Understanding metadata for TSM DP for VMware VM backups

Question

How can the size needed for metadata of VM backups be estimated to size the storage pool defined as destination by the VMCTLMC option ?

Answer

The VMCTLMC management class and storage pool destination is required when backing up virtual machines to tape or Virtual Tape using TSM for Virtual Environments. These “control” files (or “metadata”) provide a fast index to locate the virtual disk blocks backup data in TSM. The storage pool destination for these control files, associated with the VMCTLMC management class, should be on a random disk storage device type.
The easiest method to estimate the required amount storage for the VMCTLMC storage pool is to multiply the total retained VM backup data by 0.2% (0.002 decimal). The 0.2% value is an approximation and may not be appropriate for all environments, but has been shown to be valid in a sample of actual customer installations. To estimate the size requirement for the VMCTLMC storage pool, you must first estimate the total amount of retained backup storage for VMware backups. The total retained storage is total amount of data that is backed up for virtual machines, including all versions.

As an example let’s consider a virtual machine with a single vmdk of 100GB, with an average 10% daily change rate of data, with 15 days retention policy.

The total retained data is the original source data (100GB) plus the daily amount of data changed (10% * 100GB = 10GB) times the number of days retained (15). The total is (100 GB) + (10GB * 15 days) = 100GB + 150GB = 250GB. To estimate the amount of VMCTLMC data required multiple the retained data by 0.2%: 250GB * 0.2% = 0.5GB or 512 MB of disk storage.

In summary:

  • Original source data = 100 GB
  • Total retained data = 100 GB + (100 GB * .10 change rate * 15 days) = 100 GB + 150 GB = 250 GB
  • VMCTLMC data required = 250 GB * 0.002 VMCTLMC estimate = 0.5 GB

Remember that this is an approximation, thus you may want to increase or round this value up to ensure that you allocate sufficient storage pool, for example to 600GB. As with any TSM storage pool, you should monitor and set alerts for the percent utilization so you can increase the size of the storage pool if the utilization reaches a critical level, such as over 90%. Backups will fail if the VMCTLMC storage pool runs out of space. Control files associated with expired data will be removed from the VMCTLMC storage pool destination. However the timing actual expiration cycle may result in the VMCTLMC storage pool retaining some expired data and in the short term exceeding the estimate of 0.2%.

The following sections describe the analysis of VMCTLMC capacity estimation in greater detail. However, this information is generally not required if you use the simplified method of estimation using 0.2% as the guideline.

Detailed Analysis of VMCTLMC storage pool estimation method:

The VMCTLMC control files contain index information for each block of a virtual disk (vmdk) in VMware. These blocks are 16KB each. TSM stores the 16KB blocks in larger objects called “Megablocks” that are 128MB. A single control file is used for each TSM Megablock. For a 100GB vmdk, there are 800 megablocks [(100GB * 1024)/128MB]. For an initial full backup, 800 megablocks will be stored, as well as 800 control files. Each control file is a fixed size of 73KB. The total amount of space required for the control files with the initial full is 800 * 73KB = 58400KB. As a percent of retained data, the control files in this case (single full backup only) will be (58400KB)/(100GB * 1024 * 1024) = 0.000557 or 0.06% rounded. This represents the best case, or minimum, amount of VMCTL MC data as a percent of retained data.

Best case calculation (minimum distribution of changed vmdk blocks):

When incremental backups occur which affect individual 16KB vmdk blocks and not an entire 128MB TSM Megablock, only the changed data is backed up to TSM. A new control file is generated when as little as a single 16KB vmdk block is changed. The best case scenario, where the fewest megablocks are affected and the least number of new control file are created occurs when all of the changed data is consolidated in as few megablocks as possible. For example, with an incremental backup with 10% changed data on a 100GB vmdk, there would be a minimum of (10GB * 1024)/128MB = 80 changed megablocks. The amount of control file data for just this one incremental backup is 80 * 73KB = 5840KB. As a percent of the incremental backup data, the control files require (5840KB)/(10*1024*1024) = 0.000557 or 0.06% rounded of the backup data. Since the best case percentage is the same as the initial full backup, subsequent incremental backups will not change the percent calculation when calculating control file space as a percent of total retained data.

The 0.006% value calculated about represents the theoretical absolute minimum storage required for the VMCTLMC, and therefore is not a good value to use for estimation for an actual deployment.

Worst case calculation (minimum distribution of changed vmdk blocks):

It is most likely that the changed vmdk blocks are distributed to some degree throughout the virtual disk. The result of this fragmentation is to distribute the changed data over a greater number of megablocks, and results in a greater number of control files that are created. The worst case is that the changed vmdk blocks are distributed over the maximum number of megablocks possible, which in this example is 800. (There are only 800 megablocks for the 100GB vmdk, therefore this represents the maximum.) In this worst case scenario, the maximum amount of control file data that will be generated is 800 * 73KB = 58400. The associated amount of backup data for these control files is only 10GB (the 10% changed data), rather than 100GB in the case of the full backup. Therefore, the percentage of control file data (VMCTLMC) required is (58400KB)/(10GB * 1024 * 1024) = 0.00557 or 0.6% rounded. Note that this is 10 times the percentage calculated for the best case. As the number of retained incremental backups increases, the calculation of control file space as a percentage of retained backup data will approach 0.6%.

Estimation for most likely scenario

In an actual TSM for Virtual Environments deployment, neither the theoretical best case nor the worst case are likely, and the most likely scenario will be somewhere between. Based on a sampling of actual deployments, the steady state value of the ratio of control file space required compared with total retained data is approximately 0.2%. At any particular point in time the percentage may be higher such as due to delays in expiring old backup data, smaller change rates (which can result in the same amount of control file data for a smaller amount of backup data), or a wider distribution of changed data in vmdk data blocks. Best practice is to monitor the percent utilization of the VMCTLMC storage pool to determine if additional space is allocated.

written by Bosse

Jan 30

IT05265: “BACKUP VM” MAY FAIL TO PASS THE DISK VERIFICATION CHECK WITH ERRORS ANS9921E/ANS9919E

VE Comments Off on IT05265: “BACKUP VM” MAY FAIL TO PASS THE DISK VERIFICATION CHECK WITH ERRORS ANS9921E/ANS9919E
  • Tivoli Storage Manager ifincr "backup vm" may be completed with
    status failure (RC12) if client fails the virtual machine disk
    verification check.
    
    The client's console shows the following errors:
    
    ANS9921E Virtual machine disk, <VMNAME> (Hard Disk 1),
    verification check failed (1234567890/1234567890).
    ANS9919E Failed to find the expected control files for <VMNAME>.
    
    The problem occurs if  the "size on disk" value doesn't match a
    multiple of 16kb of the sector size declared in the vm control
    file.
    
    Customer/L2 diagnostic:
    
    Example:
    ***********************************
    VmVerifyIfSingleDisk():
         Found disk: Hard Disk 2
         Verifying disk backup ctls: checking size on disk vs ctl
    size
                                     coverage: Hard Disk 2.
         Num of CTLs = 425; type = IFFULL
         Skipping BITMAP.DAT file
         VM / Disk         : <VMNAME>/ Hard Disk 2
         capacity          : 32226647040
         size on disk      : 28151880704
         ctl coverage size : 28151889920
         disk included     : Yes
         prev backup ifincr: No
         ctl matches size  : No
         ctl found         : Yes
         bitmap found      : Yes
         disk used         : Yes
         result            : OK; Prev backup full; will recheck next
    ifincr
    ***********************************
    
    Generally the "ctl coverage size" is equal to the "size on
    disk". In this case the "ctl coverage size" matches the next
    16KB multiple and it should be enough to allow for a successful
    backup, however the check on the "size on disk" fails and makes
    the "backup vm" command exit with a failure.
    
    The problem occurs if the value of the "size on disk" is not a
    multiple of 16KB (16384 bytes). In the example given above the
    value "28151880704" is not a multiple of 16K.
    
    A trace gathered for an earlier VM backup belonging to the same
    ifincr chain may also show the following message:
    
    ************************
    ..\..\common\vm\vmbackvddk.cpp(6163): VmProcessExtent(): Extent
    not multiple of numSectorsPerRec 32; Last block partial read of
    14 sectors
    ************************
    
    The fullvm backup feature is not affected by this defect because
    the check is performed only during the incremental vm backup.
    
    | MDVREGR 6.4.2.001-TIV_5698MCL |
    | MDVREGR 7.1.1.000-TIV_5698MCL |
    
    Tivoli Storage Manager Versions Affected:
    All supported Tivoli Storage Manager Client on all supported
    platforms.
    
    Initial Impact:
    Medium
    
    Additional Keywords:
    vm backup fail zz62 zz63 zz64 zz71 disk vmdk ctl
    

 

Local fix

  • The disk check can be disabled, but the check was put into place
    to detect unrecoverable backups described by Flash (Alert)
    number 1684022,
    TSM data mover backups of VMware guests might be unrecoverable:
    http://www.ibm.com/support/docview.wss?uid=swg21684022
    
    If, after reading the flash and determining its applicability,
    you decide to temporarily suspend the check so that the VM can
    be backed up, then disable disk size verification by adding the
    following line in the dsm.opt file:
    VMVERIFYIFLATEST NO
    
    The VMVERIFYIFLATEST option should be re-enabled afterwards.
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED:                                              *
    * Tivoli Storage Manager for Virtual Environments version 7.1  *
    * running on all Microsoft Windows and Linux x86_64 platforms. *
    ****************************************************************
    * PROBLEM DESCRIPTION:                                         *
    * See ERROR DESCRIPTION                                        *
    ****************************************************************
    * RECOMMENDATION:                                              *
    * This issue is projected to be fixed in the Tivoli Storage    *
    * Manager Client on Windows and Linux x86_64  in level 7.1.2   *
    * Note 1: The Tivoli Storage Manager (TSM) Client is a         *
    * prerequisite to using the Data Protection for VMware. In     *
    * Data Protection for VMware environments, the TSM Client is   *
    * also known as the data mover.                                *
    * Note 2: This is subject to change at the discretion of IBM.  *
    ****************************************************************
    

Problem conclusion

  • Disk verification is successful, if ctl coverage is greater then
    disk size on disk, disk size on disk is not multiple of 16kb and
    the difference is less then 16kb.
    

written by Bosse

Oct 29

Tivoli Storage Manager backend capacity-based licensing programs

Licensing Comments Off on Tivoli Storage Manager backend capacity-based licensing programs

What are the IBM Tivoli Storage Manager capacity-based licensing programs?

IBM Tivoli Storage Manager provides three capacity-based pricing programs. These are referred to as “Suite for Unified Recovery” (SUR) and “Suite for Unified Recovery – Archive Option” (SUR-Archive). Additional details and explanation about each can be found at:

License Program Link
SUR http://www-01.ibm.com/support/docview.wss?uid=swg21500482
SUR-Archive http://www-01.ibm.com/support/docview.wss?uid=swg21596104
SUR-ProtectTier http://www-01.ibm.com/support/docview.wss?uid=swg21647140

Note the following discussion in this document relates to the “SUR” and “SUR-Archive” licensing programs. The details about planning for and using the SUR-ProtectTier program are discussed in the document linked above.

What steps should I take to prepare for running the macro?

  • Read the information about the SUR and SUR-Archive programs to determine which is applicable and should be used. You can work with your IBM account team or sales specialist/representative to help understand which should be considered.
  • Download the appropriate macro(s) based on the license program. Consider that there are different versions of the macro depending upon the version of the TSM server.
    • Consider verifying that the downloaded macro looks correct by viewing it and comparing it to the example in this document.
  • If there is a non-production TSM server (test) in your environment, consider trying the macro on the test server to familiarize yourself with how it is invoked and used.
    • Consider verifying that the generated output is correct by comparing the output to the example in this document.
  • Plan to run the macro at a time when the server workload is light or when other administrative tasks are being performed.

Is is possible to do capacity-based license measurements for versions of the product that are no longer supported?

The instructions for how to perform a capacity-based measurement for TSM V5.5 or V6.1 are available using this link:

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

It is recommended that you upgrade your TSM servers to a supported version of the product. The table below also references how to download the capacity measurement macros for these no longer supported versions of the product.

How do I get the tool(s) that perform the capacity-based license measurement?

Macro Name Use For Server Version Used By FTP Link
tsm_tb_cap_v5.macro V5.5 SUR V5 Capacity Macro
tsm_tb_cap_v5_lite.macro V5.5 SUR V5 Capacity Macro (Lite)
(See below for when and why to consider using this version of the macro for a V5.5 server)
tsm_tb_cap_v6.macro V6.1, V6.2 SUR V6.1 and V6.2 Capacity Macro
tsm_tb_cap_v63.macro V6.3, V7.1, 7.1.1* SUR V6.3 and V7.1 Capacity Macro
tsm_ar_tb_cap_V63.macro V6.3, V7.1 SUR-Archive V6.3 and V7.1 SUR-Archive Capacity Macro
tsm_tb_cap_v711_tgt.macro V7.1.1* SUR V7.1.1 Replication Target Managing Data Using Different Policies
tsm_tb_cap_v711_rc.macro V7.1.1* SUR V7.1.1 Replication Source Manage Data Using Different Policies

*Note: TSM V7.1.1 introduces the ability for TSM servers that replicate data from a source to a target to manage the data using different policies at each site. The “tsm_tb_cap_v63.macro” should be used for V7.1.1 servers if TSM server to server replication is not being used or if replication is being used and the data is not being managed differently. If V7.1.1 is being used and replication is configured to use “DISSIMILAR POLICIES” (see command QUERY REPLSERVER), than the “tsm_tb_cap_v711_tgt.macro” and “tsm_tb_cap_v711_src.macro” macros should be used. The SUR link referenced in the question above (” What are the IBM Tivoli Storage Manager capacity-based licensing programs?“) provides additional information about how to use these macros.

How do I download the macro from the FTP site?

How you download the macro from the FTP site will vary by your operating system and the browser that you are using. An example of how to do this is:

1. Click on the appropriate link from the table above.
2. For example the tsm_tb_cap_v6.macro, should appear as shown after downloading it. The example is only an excerpt and shows just the first 43 lines of the file. It is shown to illustrate the general layout and content of the macro.


3. From the browser, perform the “Save As” which is typically available from the “File” drop down menu on most browsers. It is recommended that it be saved as the name of the macro file so that the other instructions will reference the appropriate name.

For example, if you selected the macro “tsm_ar_tb_cap_v63.macro”, save this to your local disk as the same name (“tsm_ar_tb_cap_V63.macro”).

Note:
When performing the “Save As”, you want to only save the content of the page and not the HTML formatting or such that was applied when it was opened in the browser to view. On Mac OS, select “page source” to prevent saving it with the HTML tagging from the browser. From Windows, saving it as “Text Document (*.txt)” should be used as this will also prevent the HTML tagging from being embedded in the document.

4. To verify that you have done this correctly, you can open this in an editor and view the contents of the saved file and compare it to what was shown in the browser from step 2 above.

Note: The macro contains a number of lines that are many characters long and depending upon your editor settings, these may wrap (as shown above) or they may extend to the right and only be visible by scrolling to the right. It can be viewed either way, the important item is that the long lines are not broken up into many smaller lines with a “carriage return” or such imposed in the line.

What are the impacts or consequences of running the macro against my TSM server?

The macro is a TSM administrative command macro. It executes a number of SQL statements against the TSM server. The macro will require processing capacity (CPU) and memory from the TSM server. The SQL statements being run will read information from the TSM server’s database and as such it will generate I/O to the TSM server database and use memory for the database buffer pool and in-memory for the handling and processing itself.

For V6.1, V6.2, V6.3, or V7.1 servers, the SQL processing provided by DB2 is typically able to handle the resource needs of these SQL statements without issue. Notably, the statements usually run quickly on the order of minutes or tens of minutes.

For V5.5 servers, the SQL processing is highly dependent upon the CPU, memory, and I/O to the server database. In most cases, the macro is able to run in minutes, tens of minutes, or hours. In a few cases, we have seen that the macro takes many hours to run. The reason it can take a long time to run is that the SQL processing on V5.5 servers is not as efficient as what is available to the V6 and V7 TSM servers. It is also highly dependent upon the available system resources, so if the server is already near or exceeding its operational limits, than running the macro may take a long time.

For V5.5 servers, if the “tsm_tb_cap_v5.macro” macro is not able to complete or taking a long time to run, there is an alternate version of the macro available for use. See the topic in this document that discusses “What is the tsm_tb_cap_V5_lite.macro?” for more details on the purpose and use of this.

What is the “tsm_tb_cap_v5_lite.macro”?

This “lite” version of the macro reduces the complexity of the capacity measurement macro but it can only be used if the TSM server does not have any of the following types of data stored on it:

  • TSM server to server virtual volumes. This server cannot be a target for a TSM server to server virtual volume configuration.
  • TSM for Sharepoint or HSM for Windows. This server cannot store data from a TSM for Sharepoint or HSM for Windows clients or agents.
  • Data replicated from FastBack. This server cannot store data from a FastBack server replicating to this TSM server as a target.

If any of these types of data are being stored to this V5.5 server, then the “lite” version of the macro may not be used. If this V5.5 server is not storing any of these types of data, then the “lite” version of the macro can be used. Often times, it is able to run in less time and using less resources so it can complete in a shorter, more manageable timeframe.

The “tsm_tb_cap_v5_lite.macro” should be used for the following circumstances:

  • The V5.5 TSM server is already overloaded with regards to workload or available resources. For example: The server is at or near the limits of the resource capacity (CPU, memory, I/O) or the daily workloads (client data ingest, server maintenance) are taking all or most of the time available in a 24 hour window to complete.
  • The “tsm_tb_cap_v5.macro” has been tried but it takes too long to run, ran and never completed, or fails to run in this V5.5 TSM server environment.

How do I get the macro on the machine (system) where my TSM server is running?

If the system the TSM server runs on has access to the internet and the FTP link to the appropriate macro, then the macro can be accessed and saved directly from the FTP site to that system.

If the system the TSM server runs on does not have access to the internet, then the appropriate macro needs to be saved to your local environment and then transferred to the system where the TSM server is running. This can be done using file transfer tools like FTP, scp, WinSCP, or many other techniques or tools.

Note:
The macro file is simply a text file. It should be transferred from machine to machine as just a normal text file. It does not require any special handling such as to transfer it as “Binary” or such.

How do I run the macro?

The macro is run from a command prompt and uses the administrative command line client. The macro should be invoked using the following command syntax:

dsmadmc -id=<yourid> -password=<yourpassword> -dataonly=yes -outfile=<output_file_name> macro <macro_name>


The input parameters that must be specified by the administrator when this is executed are the items enclosed in ‘<‘ and ‘>’ respectively. The specific input parameters are:

  • <yourid> – This is the administrative user id that will be used to connect to the server.
  • <yourpassword> – This is the password for the administrative user id that will be used to connect to the server.
  • <capacity_file_name> – The results from the macro will be stored to this file. Select an appropriate file name use. For example, consider using the server name such as “server1.capacity”.
  • <macro_name> – The name of the macro to be run which is tsm_ar_tb_cap_v63.macro.

An example of how the macro would be invoked against a Unix, Linux, or AIX server using an xterm (or equivalent) type of interface is:

Note: The macro is invoked from the command line administrative client being run in batch mode. The macro should not be run from the command line administrative client in interactive mode.

What is the output of the macro?

The macro writes its output to the file designated by the “-outfile=…” parameter when it is invoked. See the topic “How do I run the macro?” for more explanation about how to invoke (run) the macro. An example output report for a V6 server is:

This is the general format of the report. For V5.5 servers, the “Deduplication Benefits” section simply references that TSM offers deduplication in newer versions of the product and it does not otherwise report a value. In this example, 42 TB is not being counted in the capacity measurement because the data was deduplicated and this is the savings result from the elimination of that duplicate data.

The “Details on Excluded Data” section will vary depending upon what exclusions are found. If there is no data of a specific type identified and excluded, then nothing is shown in the report. In this example, the server is using storage pools of TYPE=COPY or TYPE=ActiveData. In this case, 51 TB is identified and excluded from measurement.

This example is provided as a “guide” to understand what a typical report looks like. If the output of the macro differs significantly from what is shown this usually indicates that the macro was not correctly run. The typical reason for a significant difference in the formatting of this report is that the macro was run from the command line administrative client in interactive mode instead of being run from the system command line and using the administrative client in batch mode.

What do I do if the value reported from the macro seems wrong or incorrect?

Contact IBM service. Please provide the following information:

  • Identify the server where you are seeing the incorrect or unexpected result.
  • Provide the macro that was run to create the capacity report with the value in question:
    • Include information about the command syntax that was used to invoke the macro.
  • Provide the created capacity report that contains the value in question.
    • This is the output file specified from “-outfile=…” parameter when the administrative command line client was invoked to run the macro.
  • Collect and provide the following data from the TSM server:
    • SELECT * FROM OCCUPANCY
    • SELECT * FROM NODES
    • SELECT * FROM STGPOOLS
    • SELECT * FROM FILESPACES

written by Bosse