Tivoli Header

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 Tivoli Storage Manager 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
Move selected file spaces for a single node, as well as move a node's data located in a sequential access storage pool System, unrestricted storage, or restricted storage privilege for the source storage pool. If your authorization is restricted storage privilege and you intend to move data to another storage pool, you must also have the appropriate authority for the destination storage pool.
Deleting file spaces System or unrestricted policy
Deleting file spaces assigned to specific policy domains System, unrestricted policy, or restricted policy for those domains

Overview of Client Nodes and File Spaces

Each client is given a node name when it is registered with the server. The server views its registered nodes as clients that require services and resources from the server.

Typically, a node is equivalent to a machine as in the case of a backup-archive client installed on a user's computer for file system backups. However, multiple nodes can exist on a single machine as in the case of a SQL server machine containing both an application client for SQL database and transaction log backups, and a backup-archive client for file system backups.

Typically, each client file system is represented on the server as a unique file space that belongs to each client node. Therefore, the number of file spaces a node has depends on the number of file systems on the client machine. For example, a Windows desktop system may have multiple drives (file systems), such as C: and D:. In this case, the client's node has two file spaces on the server; one for the C: drive and a second for the D: drive. The file spaces can grow as a client stores more data on the server. The file spaces decrease as backup and archive file versions expire and the server reclaims the space. Tivoli Storage Manager does not allow an administrator to delete a node unless the node's file spaces have been deleted.

File Spaces for Clients

For client nodes running on Windows, file spaces map to logical partitions and shares. Each file space is named with the UNC name of the respective client partition or share.

For client nodes running on NetWare, file spaces map to NetWare volumes. Each file space is named with the corresponding NetWare volume name.

For clients running on Macintosh, file spaces map to Macintosh volumes. Each file space is named with the corresponding Macintosh volume name.

For clients running on UNIX, a file space name maps to a file space in storage that has the same name as the file system or virtual mount point from which the files originated. The VIRTUALMOINTPOINT option allows users to define a virtual mount point for a file system to back up or archive files beginning with a specific directory or subdirectory. For information on the VIRTUALMOUNTPOINT option, refer to the appropriate Backup-Archive Installation and User's Guide.

Supporting Unicode-Enabled Clients

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, Windows 2000, Windows 2002, Windows .NET, and Windows XP 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 Tivoli Storage Manager 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 Tivoli Storage Manager 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 Tivoli Storage Manager 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, Tivoli Storage Manager 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 Tivoli Storage Manager and the database.

A Unicode-enabled Tivoli Storage Manager client is currently available only on Windows NT, Windows 2000, Windows 2002, Windows .NET, and Windows XP. 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.

Note:
The remainder of this section will refer to these clients as Unicode-enabled clients, users of Windows NT-based operating systems, or clients.

It is strongly recommended that users of Windows NT-based operating systems migrate their non-Unicode file spaces to Unicode enabled file spaces. For more information see Backup-Archive Installation and User's Guide.

See the following sections:

Reasons for Migrating Clients to Unicode-Enabled File Spaces

Migrating Clients to Unicode-Enabled File Spaces

Querying Unicode-enabled File Spaces

Unicode-enabled Clients and Existing Backup Sets

Reasons for Migrating Clients to Unicode-Enabled File Spaces

Without Tivoli Storage Manager support for storing Unicode-enabled file spaces, some 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 Tivoli Storage Manager 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 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.

Any new file spaces that are backed up from client systems with the Unicode-enabled Tivoli Storage Manager client are automatically stored as Unicode-enabled file spaces in server storage.

Objects backed up or archived with a Unicode-enabled Tivoli Storage Manager 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 client can be restored by a German Unicode-enabled client.

Note:
Objects backed up or archived by a Unicode-enabled Tivoli Storage Manager client, cannot be restored or retrieved by a 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, Tivoli Storage Manager provides an automatic rename function for file spaces. When enabled, Tivoli Storage Manager 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. Tivoli Storage Manager 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 Tivoli Storage Manager 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 17. 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, Tivoli Storage Manager 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 Tivoli Storage Manager policy specifies how files are backed up, archived, migrated from client node storage, and managed in server storage.

  4. Understand how your Tivoli Storage Manager 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 Tivoli Storage Manager 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 Tivoli Storage Manager 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.

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.

Moving Data by Node

You can move a node's data in a sequential-access storage pool or move selected file spaces for a single node. For more information see, Moving Data by Node.

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 ]