Computing at UW-MadisonDivision of Information Technology
Students Faculty/Staff Services Services A through D Services E through L Services M through R Services S through Z Help Desk Tech Store About DoIT   

Bucky Backup

Tips for Windows v5.5+ Client Versions

Known Problems & Limitations in the Windows v5.5 Client

File Locations:

  • The Options File for the Windows TSM Client is C:\Program Files\Tivoli\TSM\baclient\dsm.opt.
  • The Scheduler Log File is C:\Program Files\Tivoli\TSM\baclient\dsmsched.log.
  • The Error Log File is C:\Program Files\Tivoli\TSM\baclient\dsmerror.log.
  • The complete TSM manual can be found in Start -> (All) Programs -> Tivoli Storage Manager -> Online Information If you'd like more information about anything discussed below, please consult the TSM manual or contact the DoIT Helpdesk.
  • The complete TSM manual can also be found online here.

Verifying Scheduler Functionality:

You can check to see that things are setup for your next scheduled backup to happen successfully by verifying that the "TSM Scheduler" service is running and that the tail-end of your dsmsched.log file has time stamps from within the last 4 hours. If the service is not running and/or the most recent time stamps in dsmsched.log are older than 4 hours, restart the "TSM Scheduler" service.

DOMAIN Statement:

By default, all local drives & Windows Objects will be backed up. To change the scope of what is considered for backup, start by modifying the DOMAIN statement. Open dsm.opt in Notepad, delete the asterisk (*) in front of DOMAIN, and list the drive letters and/or Windows Objects you want to backup. You can further restrict file backups with INCLUDE & EXCLUDE statements (next section). Here are some examples of the DOMAIN statement:

  • (Windows XP/2003/Vista/2008) Only backup files from the C: drive:
        DOMAIN C:
  • (Windows XP) Only backup files from the C: drive & Windows Objects:
        DOMAIN C: SYSTEMOBJECT
  • (Windows 2003/Vista/2008) Only backup files from the C: drive & Windows Objects:
        DOMAIN C: SYSTEMSTATE
  • (Windows XP) Only backup files from the D: & G: drives, and Windows Objects:
        DOMAIN D: G: SYSTEMOBJECT
  • (Windows 2003/Vista/2008) Only backup files from the D: & G: drives, and Windows Objects:
        DOMAIN D: G: SYSTEMSTATE
  • (Windows XP/2003/Vista/2008) Only backup files from the C: drive & the named network share:
        DOMAIN C: \\myserver.dept.wisc.edu\myshare

Please note that any network shares you want to backup must be entered at the DOMAIN statement line in UNC format (example given above). Do not list network shares via their mapped drive letters. If you want the TSM Scheduler to backup the network shares, the "TSM Scheduler" service's "Log On" tab must be updated to run as an admin-level user who can browse to those network shares without being prompted for credentials.

Please note that if you want to be able to do a disaster recovery with your TSM data, you must backup SYSTEMOBJECT (Windows XP) or SYSTEMSTATE (Windows 2003/Vista/2008).

Be sure to save changes to dsm.opt & restart your TSM Scheduler service for changes to take effect. See this document for more information on reducing backup costs.

INCLUDE & EXCLUDE Statements:

INCLUDE & EXCLUDE statements are entered into the options file and only apply to files & directories that are within the scope of your DOMAIN. EXCLUDE.DIR statements (which exclude entire directories) get processsed first. Next, regular INCLUDE & EXCLUDE statements are read from the bottom-up. The first one found that matches a particular file is the one used. You only need to put quotes around a drive letter & path if a section of the path is longer than 8 characters and/or there are spaces in the path, but you can put quotes around all drive letters & paths if you want. Here are some examples:

  • Exclude any directory named "temp" on the root of any drive. Note that ? means to match any drive letter:
        EXCLUDE.DIR ?:\temp
  • Exclude any directory named "stuff not to back up" where ever it might exist. Note that adding "...\" to a path means "match any number of directories":
        EXCLUDE.DIR "?:\...\stuff not to back up"
  • Exclude any file that has a dmp extension where ever it might exist:
        EXCLUDE ?:\...\*.dmp
  • Exclude all files from "D:\something", but allow files in sub directories of "D:\something" to be backed up. Note the lack of "...\":
        EXCLUDE "D:\something\*.*"
  • Exclude all files from "C:\Program Files\My Application" & any sub directories except for files that have a log extension. Note that the INCLUDE is below the EXCLUDE statement so that it gets processed first. We can't use EXCLUDE.DIR on the "My Application" directory here because that would get processed before any regular INCLUDE's or EXCLUDE's, effectively nullifying the INCLUDE statement. Also, the entire subdirectory structure will be backed up (the EXCLUDE statement only applies to files):
        EXCLUDE "C:\Program Files\My Application\...\*.*"
        INCLUDE "C:\Program Files\My Application\...\*.log"
  • Exclude everything from the C: drive except for the entire "C:\Documents and Settings" directory. Note that this only excludes all the non-"C:\Documents and Settings" files on C: -- an empty directory structure of the entire C: drive will still be backed up.:
        EXCLUDE C:*.*
        INCLUDE "C:\Documents and Settings\...\*.*"
  • Here are two ways to exclude all files from the D: drive. Note the lack of a backslash in the first one which means "match the file anywhere on the drive". Also, this only excludes all the files on D: -- an empty directory structure of the entire D: drive will still be backed up. If you want to exclude the entire D: drive, it is best to define a DOMAIN statement that does not reference D:
        EXCLUDE D:*.*
        EXCLUDE D:\...\*.*

Be sure to save changes to dsm.opt & restart your TSM Scheduler service for changes to take effect. See this document for more information on reducing backup costs.

Using Alternate Management Classes:

Let's say, for instance, you want to keep 10 versions of all Active & Inactive files for 365 days within "C:\Important Files", and only 2 versions of all other Active files, and only 1 version of all other Inactive Files, both only for 30 days. You should send an email to DoIT SysOps similar to this:

  • Hello - My node name is XXXXXX and I'd like 2 management classes created: 1 that keeps 10 versions of all active & inactive files for 365 days. And 1 that keeps 2 versions of all active & 1 version of all inactive files for 30 days. Thanks.

And suppose SysOps responds telling you that the first one is called 10_VERSIONS_365_DAYS and the second is called 2_VERSIONS_1_INACTIVE_30_DAYS. Here is how you'd bind your files to those management classes. Note that the Important Files are included & bound to the 10 versions management class below the other statement to make sure it gets processed first. All other files will match the Include statement above it:

  • INCLUDE ?:*.* 2_VERSIONS_1_INACTIVE_30_DAYS
    INCLUDE "C:\Important Files\...\*.*" 10_VERSIONS_365_DAYS

Be sure to save changes to dsm.opt & restart your TSM Scheduler service for changes to take effect.

Encrypting your backups:

It is possible to do transport & storage encryption via keys. Encryption keys cannot be "reset", so if you forget or loose your key, your data is not retrievable. The 3 types of key encryption are:

  • ENCRYPTKEY GENERATE - The key is autogenerated & stored in the TSM server database. You don't need to worry about losing the key, but the TSM Admins can now restore your encrypted data, and if anyone is able to guess your node's password, they can restore the encrypted data too. On the other hand, if you are restoring encrypted data to a different machine, or a freshly reinstalled machine, you don't need to know the key. This is the least secure, but easiest to use method of key encryption. All it really gets you is transport & storage encryption. It doesn't make it any harder to decrypt anything if you can get to the backed up data somehow.
  • ENCRYPTKEY PROMPT - You need to create & keep track of the key, and enter it every time you transfer encrypted data. This is a problem for scheduled backups that send over encrypted files, because the scheduler will stop with a prompt asking for the encryption key, and the backup will fail at that point. You could exclude your encrypted files from the scheduled backups and handle them separately though. Neither TSM Admins nor anyone who is able to guess your node's password would be able to restore the encrypted data without knowing the key. This is the most secure, but least convenient method of key encryption.
  • ENCRYPTKEY SAVE - You need to create the key, but it is stored in the local registry. The TSM client will use the key whenever it needs to, including during scheduled backups, which should run to completion without problems once you've done at least 1 manual backup & entered the key. You will only need to re-enter the key if the saved one in the registry goes away somehow, or if you are restoring to a different or freshly reinstalled machine. Neither TSM Admins nor anyone who is able to guess your node's password would be able to restore the encrypted data without knowing the key.

Which type of key encryption to use:

  • If you don't ever want there to be a possibility of being unable to restore your encrypted data, you have a good long password protecting your node, and you trust the TSM Admins & other local admins on your machine, use ENCRYPTKEY GENERATE.
  • If the files you are encrypting are the most sensitive types of files imaginable and you can't even risk allowing other admins of the machines to restore the encrypted files, use ENCRYPTKEY PROMPT. In this case, I would suggest creating a separate node for this data, storing the data locally in an encrypted folder on an NTFS volume. (Right-Click -> Properties -> Advanced button -> check "Encrypt contents to secure data), and doing all backups manually. Only your user account on Windows can see the data locally, and only people who know the encryption key can restore the data from backup. You are responsible for keeping track of the encryption key. If you lose it, your backed up data is not retrievable.
  • If you don't trust the TSM Admins and/or you don't want people who were able to guess your node's password to be able to restore your encrypted data, but you do trust the other admins on your machine, use ENCRYPTKEY SAVE. You are responsible for keeping track of the encryption key.

How to use key encryption:

  • Enter the relevant ENCRYPTKEY line in your dsm.opt file, then identify which files should be encrypted via INCLUDE.ENCRYPT. The way you identify these files is like how you bind certain files to a different management class (see above). But rather than entering the management class name at the end of the INCLUDE statement, you just change it to INCLUDE.ENCRYPT & don't enter anything after the file specification. Restart your TSM Scheduler service after saving changes to dsm.opt. If you are using GENERATE, you are done. If you are using SAVE, you need to run a manual backup so that you get prompted for a key that will be saved to the registry. If you are using PROMPT, you always need to do your backups/restores manually.
  • Always use COMPRESSION YES. This is the default in the dsm.opt file. The reason is that only the client can compress the data before encrypting it & sending it to the server. The server itself cannot compress it.
  • Be aware that using encryption uses more CPU.

Example - The following will handle file encryption transparently, and will encrypt everything that is not explicitly INCLUDE'd or EXCLUDE'd below the INCLUDE.ENCRYPT line:

  • ENCRYPTKEY GENERATE
    INCLUDE.ENCRYPT ?:*.*

File Space Maintenance:

See the first part of this document for how to delete file spaces.

Journal Based Backups:

If your node has lots of files (hundreds of thousands+), and you know that only a small or moderate amount of them will be changing from day to day, you might want to enable Journal Based Backups. This will reduce the amount of time it takes TSM to process all of them during backups. Please see this document for more info.

Extra Tips:

  1. Please read through the Windows Disaster Recovery information.

  2. To tell what will be backed up during your next scheduled backup by starting the GUI client and going into “Backup.” If you have restricted your backup domain to just a couple of drives, all of them will still show up here, but only files that fall within your specified domain will be considered for backup. Only pay attention to the drives that are part of your domain. Directories that have been excluded with Exclude.Dir statements will not show up at all and won’t be backed up. Files that have been excluded with a regular Exclude statement will be visible, but a little red x or “not sign” will appear over their icons and the files won’t be backed up either.