Tivoli Storage Manager for Windows: Administrator's Guide


Managing File Spaces

A file space name identifies a group of files that are stored as a logical unit in server storage. Administrators manage file spaces in which TSM stores each client node's data. See Overview of Client Nodes and File Spaces for more information.

Administrators can perform the following activities when managing file spaces:

Task Required Privilege Class
Determine when existing file spaces are renamed to allow for the creation of new Unicode-enabled file spaces System, unrestricted policy privilege, or restricted policy privilege for the policy domain to which the client node is assigned.
Displaying information about file spaces Any administrator
Deleting file spaces System or unrestricted policy
Deleting file spaces assigned to specific policy domains System, unrestricted policy, or restricted policy for those domains

Supporting Unicode-Enabled Clients (Windows NT and Windows 2000)

Unicode is a universal character encoding standard that supports the interchange, processing, and display of text that is written in any of the languages of the modern world. For Windows NT and Windows 2000 systems with the Unicode-enabled client, the server supports storing file spaces with Unicode file space names, directory names, and file names in server storage. The file spaces in server storage that have Unicode names are called Unicode-enabled file spaces. Support for Unicode names enables a client to successfully process a TSM operation even when the file spaces contain directory names or files in multiple languages, or when the client uses a different code page than the server.

New clients storing data on the server for the first time require no special set-up. If the client has the latest TSM client software installed, the server automatically stores Unicode-enabled file spaces for that client.

However, if you have clients that already have data stored on the server and the clients install the Unicode-enabled TSM client software, you need to plan for the migration to Unicode-enabled file spaces. To allow clients with existing data to begin to store data in Unicode-enabled file spaces, TSM provides a function for automatic renaming of existing file spaces. The file data itself is not affected; only the file space name is changed. Once the existing file space is renamed, the operation creates a new file space that is Unicode enabled. The creation of the new Unicode-enabled file space for clients can greatly increase the amount of space required for storage pools and the amount of space required for the server database. It can also increase the amount of time required for a client to run a full incremental backup, because the first incremental backup after the creation of the Unicode-enabled file space is a full backup.

When clients with existing file spaces migrate to Unicode-enabled file spaces, you need to ensure that sufficient storage space for the server database and storage pools is available. You also need to allow for potentially longer backup windows for the complete backups.

Note:
Once the server is at the latest level of software that includes support for Unicode-enabled file spaces, you can only go back to a previous level of the server by restoring an earlier version of TSM and the database.

A Unicode-enabled TSM client is currently available only on Windows NT and Windows 2000. Data in a Unicode code page from any other source, including down-level clients and API clients, will not be identified or treated as Unicode enabled.

See the following sections:

Deciding Whether Clients Need Unicode-Enabled File Spaces

Migrating Clients to Unicode-Enabled File Spaces

Querying Unicode-enabled File Spaces

Unicode-enabled Clients and Existing Backup Sets

Deciding Whether Clients Need Unicode-Enabled File Spaces

Without the TSM support for storing Unicode-enabled file spaces, some Windows NT and Windows 2000 clients have experienced backup failures when file spaces contain names of directories or files in multiple languages, or have names that cannot be converted to the server's code page. When TSM cannot convert the code page, the client may receive one or all of the following messages if they were using the command line: ANS1228E, ANS4042E, and ANS1803E. Clients that are using the GUI may see a "Path not found" message. If you have Windows NT and Windows 2000 clients that are experiencing such backup failures, then you need to migrate the file spaces for these clients to ensure that these systems are completely protected with backups. If you have a large number of clients, set the priority for migrating the clients based on how critical each client's data is to your business. See Migrating Clients to Unicode-Enabled File Spaces.

If you have Windows NT and Windows 2000 clients that are not having problems backing up any files, you do not need to migrate the file spaces for these clients. You can choose whether to migrate their existing file spaces after these clients install the latest TSM client software. See Migrating Clients to Unicode-Enabled File Spaces and Choosing to Keep File Spaces that are Not Unicode Enabled.

Any new file spaces that are backed up from Windows NT and Windows 2000 systems with the Unicode-enabled TSM client are automatically stored as Unicode-enabled file spaces in server storage.

Objects backed up or archived with a Unicode-enabled TSM client in any supported language environment can be restored or retrieved with a Unicode-enabled client in the same or any other supported language environment. This means, for example, that files backed up by a Japanese Unicode-enabled TSM client can be restored by a German Unicode-enabled TSM client.

Note:
Objects backed up or archived by a Unicode-enabled TSM client, cannot be restored or retrieved by a TSM client that is not Unicode enabled.

Migrating Clients to Unicode-Enabled File Spaces

To allow clients with existing data to migrate to Unicode-enabled file spaces, TSM provides an automatic rename function for file spaces. When enabled, TSM uses the rename function when it recognizes that a file space that is not Unicode enabled in server storage matches the name of a file space on a client. The existing file space in server storage is renamed, so that the file space in the current operation is then treated as a new, Unicode-enabled file space. For example, if the operation is an incremental backup at the file space level, the entire file space is then backed up to the server as a Unicode-enabled file space.

The following example shows how this process works when automatic renaming is enabled from the server, for an existing client node that has file spaces in server storage.

  1. The administrator updates a client node definition by issuing an UPDATE NODE command with the parameter, AUTOFSRENAME YES.
  2. The client processes an incremental back up.
  3. TSM processes the back up as follows:
    1. Renames the existing file space (_OLD)
    2. Creates a new Unicode-enabled file space
    3. Processes the back up in the current operation to the new Unicode-enabled file space

Attention: If you force the file space renaming for all clients at the same time, backups can contend for network and storage resources, and storage pools can run out of storage space.

Before you allow automatic renaming of file spaces for Unicode-enabled TSM clients, read the following sections.

The Rules for Automatically Renaming File Spaces

Options for Automatically Renaming File Spaces

Planning for Unicode Versions of Existing Client File Spaces

How Clients are Affected by the Migration to Unicode

Example of a Migration Process

Options for Automatically Renaming File Spaces

As an administrator, you can control whether the file spaces of any existing clients are renamed to force the creation of new Unicode-enabled file spaces. By default, no automatic renaming occurs. To control the automatic renaming, use the parameter AUTOFSRENAME when you register or update a node. You can also allow clients to make the choice. Clients can use the client option AUTOFSRENAME.

Note:
The setting for AUTOFSRENAME affects only clients that are Unicode enabled.

You have these options:

The following table summarizes what occurs with different parameter and option settings.

Table 14. Effects of AUTOFSRENAME Settings

Parameter on the server (for each client) Option on the client Result for file spaces Is the file space renamed?
Yes Yes, No, Prompt Renamed Yes
No Yes, No, Prompt Not renamed No
Client Yes Renamed Yes
No Not renamed Yes
Prompt Command-line or GUI: The user receives a one-time only prompt about renaming Depends on the response from the user (yes or no)
Client Scheduler: Not renamed (prompt appears during the next command-line or GUI session) No

The Rules for Automatically Renaming File Spaces

With its automatic renaming function, TSM renames a file space by adding the suffix _OLD. For example:

Original file space \\maria\c$
Renamed file space \\maria\c$_OLD

If the new name would conflict with the name of another file space, a number is added to the suffix. For example:

Original file space \\maria\c$ Other existing file spaces:
\\maria\c$_OLD
\\maria\c$_OLD1
Renamed file space \\maria\c$_OLD2

If the new name for the file space exceeds the limit of 64 characters, the file space name is truncated on the right before the suffix _OLD is added.

Planning for Unicode Versions of Existing Client File Spaces

You need to consider the following factors in your planning:

To minimize problems, you need to plan the storage of Unicode-enabled file spaces for clients that already have existing file spaces in server storage.

  1. Determine which clients need to migrate.

    Clients that have had problems with backing up files because their file spaces contain names of directories or files that cannot be converted to the server's code page should have the highest priority. Balance that with clients that are most critical to your operations. If you have a large number of clients that need to become Unicode enabled, you can control the migration of the clients.

    Change the rename option for a few clients at a time to keep control of storage space usage and processing time. Also consider staging migration for clients that have a large amount of data backed up.

  2. Allow for increased backup time and network resource usage when the Unicode-enabled file spaces are first created in server storage.

    Based on the number of clients and the amount of data those clients have, consider whether you need to stage the migration. Staging the migration means setting the AUTOFSRENAME parameter to YES or CLIENT for only a small number of clients every day.

    Note:
    If you set the AUTOFSRENAME parameter to CLIENT, be sure to have the clients (that run the client scheduler) set their option to AUTOFSRENAME YES. This ensures the file spaces are renamed.
  3. Check the current storage usage for the clients that need to become Unicode enabled.

    You can use the QUERY OCCUPANCY command to display information on how much space each client is currently using. Initially, clients will need only the amount of space used by active files. Therefore, you need to estimate how much of the current space is used by copies (different versions of the same file). Migration will result in a complete backup at the next incremental backup, so clients will need space for that backup, plus for any other extra versions that they will keep. Therefore, the amount of storage required also depends on policy (see the next step). Your TSM policy specifies how files are backed up, archived, migrated from client node storage, and managed in server storage.

  4. Understand how your TSM policies affect the storage that will be needed.

    If your policies expire files based only on the number of versions (Versions Data Exists), storage space required for each client will eventually double, until you delete the old file spaces.

    If your policies expire files based only on age (Retain Extra Versions), storage space required for each client will increase initially, but will not double.

    If your policies use both the number of versions and their age, each client will need less than double their current usage.

  5. Estimate the effect on the database size.

    The database size depends on the number of files in server storage, as well as the number of versions of those files. As Unicode-enabled file spaces are backed up, the original file spaces that were renamed remain. Therefore, the server requires additional space in the database to store information about the increased number of file spaces and files.

    See Estimating and Monitoring Database and Recovery Log Space Requirements.

  6. Arrange for the additional storage pool space, including space in copy storage pools, based on your estimate from step 3 and 4.
  7. Check the server database space that is available and compare with your estimate from step 5.
  8. Ensure that you have a full database backup before you proceed with migration of Unicode-enabled file spaces. See Backing Up the Database.
  9. Consider how you will manage the renamed file spaces as they age. The administrator can delete them, or the clients can be allowed to delete their own file spaces.

How Clients are Affected by the Migration to Unicode

The server manages a Unicode-enabled client and its file spaces as follows:

Example of a Migration Process

This section gives one possible sequence for migrating clients. Assumptions for this scenario are:

The following is a possible migration process:

  1. Have all clients install the Unicode-enabled TSM client software.
  2. Migrate the file servers first. For clients that are file servers, update the AUTOFSRENAME parameter to enable automatic renaming for the file spaces. For example, if the client node names for all file servers begin with FILE, enter the following command:
    update node file* autofsrename=yes
    
    This forces the file spaces to be renamed at the time of the next backup or archive operation on the file servers. If the file servers are large, consider changing the renaming parameter for one file server each day.
  3. Allow backup and archive schedules to run as usual. Monitor the results.
    1. Check for the renamed file spaces for the file server clients. Renamed file spaces have the suffix _OLD or _OLDn, where n is a number. (See The Rules for Automatically Renaming File Spaces.)
    2. Check the capacity of the storage pools. Add tape or disk volumes to storage pools as needed.
    3. Check database usage statistics to ensure you have enough space.
  4. Migrate the workstation clients. For example, migrate all clients with names that start with the letter a.
    update node a* autofsrename=yes
    
  5. Allow backup and archive schedules to run as usual that night. Monitor the results.
  6. After sufficient time passes, consider deleting the old, renamed file spaces. See Managing the Renamed File Spaces.

Managing the Renamed File Spaces

The file spaces that were automatically renamed (_OLD) to allow the creation of Unicode-enabled file spaces continue to exist on the server. Users can still access the file versions in these file spaces.

Because a renamed file space is not backed up again with its new name, the files that are active (the most recent backup version) in the renamed file space remain active and never expire. The inactive files in the file space expire according to the policy settings for how long versions are retained. To determine how long the files are retained, check the values for the parameters, Retain Extra Versions and Retain Only Versions, in the backup copy group of the management class to which the files are bound.

When users no longer have a need for their old, renamed file spaces, you can delete them. If possible, wait for the longest retention time for the only version (Retain Only Version) that any management class allows. If your system has storage constraints, you may need to delete these file spaces before that.

Querying Unicode-enabled File Spaces

You can determine which file spaces are Unicode-enabled by querying all of the file spaces:

query filespace
+--------------------------------------------------------------------------------+
|Node Name  Filespace   FSID  Platform  Filespace    Is     Capacity   Pct       |
|           Name                        Type      Filespace     (MB)  Util       |
|                                                 Unicode?                       |
|---------- ----------- ----  -------  --------- --------- -------- -----        |
|SUE        \\sue\c$       1  WinNT     NTFS        Yes     2,502.3  75.2        |
|SUE        \\sue\d$       2  WinNT     NTFS        Yes     6,173.4  59.6        |
|JOE        \\joe\c$       1  WinNT     NTFS        No     12,299.7  31.7        |
|                                                                                |
+--------------------------------------------------------------------------------+

To query a specific Unicode-enabled file space, it may be more convenient to use the file space identifier (FSID) than the file space name. File space names for Unicode-enabled file spaces may not be readable when displayed in the server's code page. Attempting to enter the name of a Unicode-enabled file space may not work because it depends on the server's code page and conversion routines that attempt to convert from the server's code page to Unicode. See Displaying Information about File Spaces for details.

Unicode-enabled Clients and Existing Backup Sets

A client can have a backup set that contains both file spaces that are Unicode-enabled and file spaces that are not Unicode-enabled. The client must have the same level of TSM or higher to restore the data in the backup set. For example, a Version 4.1.0 client backs up file spaces, and then upgrades to Version 4.2.0 with support for Unicode-enabled file spaces. That same client can still restore the non-Unicode file spaces from the backup set.

Unicode-enabled file spaces in a backup set can only be accessed by a Unicode-enabled client, and not by an earlier version of the client. The server allows only Unicode-enabled clients to restore data from Unicode-enabled file spaces. For information about restoring backup sets, see Restoring Backup Sets from a Backup-Archive Client.

Choosing to Keep File Spaces that are Not Unicode Enabled

If a client that is using Windows NT or Windows 2000 does not want their file spaces Unicode enabled, the client can install the TSM client for Windows 95/98 on their workstation.

The administrator can also leave the AUTOFSRENAME parameter set to the default of NO for these clients.

Displaying Information about File Spaces

You can display file space information to:

You display file space information by identifying the client node name and file space name.

Note:
File space names are case-sensitive and must be entered exactly as known to the server.

For example, to view information about file spaces defined for client node JOE, enter:

query filespace joe *

The following figure shows the output from this command.


+--------------------------------------------------------------------------------+
|Node Name  Filespace   FSID  Platform  Filespace    Is     Capacity   Pct       |
|           Name                        Type      Filespace     (MB)  Util       |
|                                                 Unicode?                       |
|---------- ----------- ----  -------  --------- --------- -------- -----        |
|JOE        \\joe\c$       1  WinNT     NTFS        Yes     2,502.3  75.2        |
|JOE        \\joe\d$       2  WinNT     NTFS        Yes     6,173.4  59.6        |
|                                                                                |
+--------------------------------------------------------------------------------+

When you display file space information in detailed format, the Filespace Name field may display file space names as "...". This indicates to the administrator that a file space does exist but could not be converted to the server's code page. Conversion can fail if the string includes characters that are not available in the server code page, or if the server has a problem accessing system conversion routines.

File space names and file names that can be in a different code page or locale than the server do not display correctly on the administrator's Web interface or the administrative command-line interface. The data itself is backed up and can be restored properly, but the file space name or file name may display with a combination of invalid characters or blank spaces. Refer to Administrator's Reference for details.

Deleting File Spaces and Client Nodes

You can delete a client node from a server, but first you must delete all of that client's data from server storage by deleting any file spaces that belong to the node.

Deleting a File Space

Administrators may want to delete a file space when:

When a node has more than one file space and you issue a DELETE FILESPACE command for only one file space, a QUERY FILESPACE command for the node during the delete process shows no file spaces. When the delete process ends, you can view the remaining file spaces with the QUERY FILESPACE command.

Note:
After you delete all of a client node's file spaces, you can delete the node with the REMOVE NODE command. See Deleting Client Nodes for more details.


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]