adsm.se

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

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

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

Example Output

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

Software Requirements

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

Running the Sample Powershell Script from a Scheduler

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

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

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

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

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

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

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

Complete the following steps:

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

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

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

copy FastBackClient.ini FastBackClient.previous

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

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

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

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

Fixes:

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

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

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

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

•  
  %Program Files%\Junction\junction.exe <Ftp_root_dir>\REP_BranchName\STAGE <Ftp_root_dir>\REP_BranchName

a. Under REP_BranchName, delete the STAGE directory.
b. Use the junction.exe application to recreate the STAGE directory. To complete this step, enter the following command:

6. Restart the FastBack Disaster Recovery Server.

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

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

Fixes:

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

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

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

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

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

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

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

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

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

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

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

Fixes:

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

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

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

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

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

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

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

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

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

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

(Windows 2008 only)

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

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

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

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

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

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

Fixes:

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

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

The reason for this drastic difference, is that the estimate only covers the utilized data. Any portion of the database that is assigned, but not utilized, will not be included in the estimate. Therefore, the difference between the utilized data and the assigned capacity should be roughly included in the final estimate by the TSM Administrator when making a determination on if the reorganization is time and space effective.

C:\ProgramData\IBM\DB2\DB2TSM1\

Windows 2003:

The default location is:

C:\Documents and Settings\All Users\Application Data\IBM\DB2\DB2TSM1

The example below shows two Server instances, SERVER1 and SERVER2.

Unnamed[1] VOLUME_NAME
—————— ——————
CHECKIN LIBVOLUME LIBRARYNAME /tmp/00000000.BFS
CHECKIN LIBVOLUME LIBRARYNAME /tmp/00000001.BFS
CHECKIN LIBVOLUME LIBRARYNAME /tmp/00000002.BFS
CHECKIN LIBVOLUME LIBRARYNAME /tmp/00000003.BFS
CHECKIN LIBVOLUME LIBRARYNAME /tmp/00000004.BFS
CHECKIN LIBVOLUME LIBRARYNAME /tmp/00000005.BFS
CHECKIN LIBVOLUME LIBRARYNAME /tmp/00000006.BFS
CHECKIN LIBVOLUME LIBRARYNAME /tmp/00000007.BFS
CHECKIN LIBVOLUME LIBRARYNAME /tmp/00000008.BFS
CHECKIN LIBVOLUME LIBRARYNAME /tmp/00000009.BFS
CHECKIN LIBVOLUME LIBRARYNAME /tmp/0000000A.BFS

This will redirect the output to a file, checkinoffsite.file, that will contain a checkin command for every offsite volume. This file can be manipulated to create a script or macro.

db2 “get db cfg for <db name>”

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

IMPACT TO THE TIVOLI STORAGE MANAGER SERVER

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

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

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

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

TUNING THE DB2 LOCKLIST

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

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

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

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

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

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

MEMORY REQUIREMENTS FOR LOCKLIST

122000 LOCKLIST = 499MB (122000 X 4096)

244000 LOCKLIST = 1GB (244000 X 4096)

1220000 LOCKLIST = 4.9 GB (1220000 X 4096)

Example #1

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

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

Total concurrent data movement – 2TB

DB2 LOCKLIST recommendation – 588000

Additional impact to system memory (potential) – 2.4 GB

Example #2

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

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

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

Total concurrent data movement/management – 3.5 TB

DB2 LOCKLIST recommendation – 954000

Additional impact to system memory (potential) – 3.9GB

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

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

XXXXXXXXX = LOCKLIST value

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

db2 “get db cfg for <db name>”

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

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