Jul 16

IC65242: DOMINO SERVER MAY NOT RESTART AFTER A FASTBACK BACKUP

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

Error description

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

     

    • Local fix

  • Use updated scripts

     

    • Problem summary

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

     

    • Problem conclusion

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

    • Temporary fix

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

     

    • written by Bosse

    Jul 16

    IC68650: FASTBACK SERVER MAY REPORT ABORTED SNAPSHOT WHEN THERE IS NOTHING TO CLEAN-UP

    Client, Server Comments Off on IC68650: FASTBACK SERVER MAY REPORT ABORTED SNAPSHOT WHEN THERE IS NOTHING TO CLEAN-UP

    Error description

  • FastBack may sent out a snapshot abort using the external
notification email for consolidated (cleanup) snapshot although
there was nothing to cleanup.

In Logs

1 .C:Documents and Settings\All Users\Application
Data\Tivoli\TSM\FastBack\server\events - EventJobX -

2010/05/07 19:36:42 FBSS7037E  Procedure aborted
2010/05/07 19:36:42 FBSS1031I  **Consolidated**
2010/05/07 19:36:42 FBSS1041I  Procedure initiated.

2. C:Documents and Settings\All Users\Application
Data\Tivoli\TSM\FastBack\server\ - Server logs -

DM_CLEANUP_BuildCleanUpMAP: Nothing to do, No change since last
cleanup
DM_CLEANUP_Dispatch: DM_CLEANUP_BuildCleanUpMAP (job [5])
required abort of job
JOB_S_AddEvent: [5] 2010/05/07 15:02:42 FBSS1031I
**Consolidated**

     

    • Local fix

  •  Ignore the failure messages

     

    • Problem summary

  • ****************************************************************
* USERS AFFECTED: All Fastback Users Running Snapshot Cleanup. *
****************************************************************
* PROBLEM DESCRIPTION: See ERROR DESCRIPTION.                  *
****************************************************************
* RECOMMENDATION: Apply fixing level when available. This      *
*                 problem is currently projected to be fixed   *
*                 in level 6.1.1 and 5.5.7. Note that this     *
*                 is subject to change at the discretion of    *
*                 IBM.                                         *
****************************************************************

    • written by Bosse

    Jul 09

    Automating Database Availability Group backups for Exchange 2010

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

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

     

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

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

    Example Output

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

    Software Requirements

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

    Running the Sample Powershell Script from a Scheduler

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

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

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

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

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

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

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

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

    Länk to page at IBM

    written by Bosse

    Jul 01

    IC69506: AUTOMATIC REORGS OF DATABASE INDEXES DOES NOT OCCUR

    DB LOG, DB2 Comments Off on IC69506: AUTOMATIC REORGS OF DATABASE INDEXES DOES NOT OCCUR

    Error description

    The TSM Server will perform automatic reorgs of database tables,
    however, online reorgs of the table indexes do not occur
    automatically.  By default, the DB2 policy definitions do not
    allow for automatic, online reorgs of database table indexes,
    thus preventing the TSM Server from performing reorgs of the
    various indexes.  This can result in the continued growth of the
    TSM database.

    Platforms affected:
    All TSM 6.1.x and 6.2.x Servers

    Customer/L2 Diagnostics:
    The DB2 ‘reorgchk’ utility can be used to determine if a reorg
    of the table indexes is required.

    Platforms affected:
    All TSM 6.1.x and 6.2.x Servers

    The DB2 ‘reorgchk’ utility can be used to determine if a reorg
    of the table indexes is required.

    Local fix

    The following actions can be performed to modify the DB2 policy
definitions to allow for automated, online reorgs of the table
indexes:

1. Login to the host machine where the TSM Server is running as
   the DB2 instance owner (eg. 'tsminst1')
2. Issue the following command to connect to the TSM database:

   $ db2 connect to tsmdb1

3. Issue the following command to export the existing DB2
   automatic maintenance definitions to a file named
   AutoReorg.xml:

   $ db2 "call sysproc.automaint_get_policyfile(
   'AUTO_REORG','AutoReorg.xml')"
4. The file which contains the exported data is placed by the
   stored procedure in the following location:

   <instance dir>/sqllib/tmp/AutoReorg.xml

5. Make a copy of the AutoReorg.xml file as this file can be
   used later in the event it becomes necessary to revert back
   to the original configuration.
6. Modify the AutoReorgNew.xml file as follows:

   - change the indexReorgMode value from "Offline" to "Online"
   - change the useSystemTempTableSpace value from "false" to
     "true"

7. Issue the following command to activate the new DB2 automatic
   maintenance definitions:

   $ db2 "call sysproc.automaint_set_policyfile(
   'AUTO_REORG','AutoReorgNew.xml')"

Automatic, online reorgs of the database table indexes can now
be performed by TSM.  The following command can be issued
periodically to verify that automatic reorgs of the indexes are
occurring as expected:

   $ db2 list history reorg all for db tsmdb1

NOTE: Should it be necessary to disable automated reorgs of the
table indexes, issue the following command to update the DB2
automatic maintenance definitions back to their original values:

   $ db2 "call sysproc.automaint_set_policyfile(
   'AUTO_REORG','AutoReorg.xml')"

NOTE: The procedures listed above are specific to UNIX hosts.
These procedures may also apply to DB2 running on Windows hosts
with the following distinctions:

   - all DB2 commands must be run in a DB2 command window
   - the policy definition file on Windows is named
     DB2AutoReorgPolicy.xml.  Substitute this policy file name
     in place of AutoReorg.xml.

It is recommended that the enabling/disabling of automatic index
reorgs be performed at a time when the TSM Server is quiesced.

    written by Bosse

    Jul 01

    2TB limit on Fastback

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

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

    Complete the following steps:

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

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

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

      copy FastBackClient.ini FastBackClient.previous

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

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

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

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

    Fixes:

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

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

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

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

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

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

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

    6. Restart the FastBack Disaster Recovery Server.

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

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

    Fixes:

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

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

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

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

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

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

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

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

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

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

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

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

    Fixes:

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

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

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

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

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

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

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

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

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

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

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

    (Windows 2008 only)

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

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

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

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

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

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

    Fixes:

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

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

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

    written by Bosse