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 |
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.
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
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.
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.
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
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.
You have these options:
TSM does not automatically rename client file spaces when the client system upgrades to the Unicode-enabled TSM client. This setting can help an administrator control how many clients' file spaces can be renamed at one time. The administrator can determine how many Unicode-enabled clients exist by using the QUERY NODE FORMAT=DETAILED command. The output displays the client level. A Unicode-enabled client is on a Windows NT or Windows 2000 system at TSM Version 4.2.0 or higher.
TSM automatically renames client file spaces in server storage when the client upgrades to the Unicode-enabled client and runs one of the following operations: archive, selective backup, full incremental backup, or partial incremental backup. TSM automatically renames the file spaces that are specified in the current operation and creates new, Unicode-enabled file spaces where files and directories are stored to complete the operation. Other file spaces that are not specified in the current operation are not affected by the rename. This means a client can have mixed file spaces. See The Rules for Automatically Renaming File Spaces for how the new name is constructed.
Attention: If you force the file space renaming for all clients at the same time, client operations can contend for network and storage resources, and storage pools can run out of storage space.
If you use this value for a client node, the client can set its AUTOFSRENAME option in its options file. The client option determines whether file spaces are renamed (YES or NO), or whether the user is prompted for renaming at the time of a TSM operation (PROMPT).
The default value for the client option is PROMPT. When the option is set for prompting, the client is presented with a choice about renaming file spaces. When a client that has existing file spaces on server storage upgrades to the Unicode-enabled client, and the client runs a TSM operation with the server, the user is asked to choose whether to rename the file spaces that are involved in the current operation.
The client is prompted only once about renaming a particular file space.
If the client does not choose to rename the file space, the administrator can later rename the file space so that a new Unicode-enabled file space is created the next time the client processes an archive, selective backup, full incremental backup, or partial incremental backup.
Attention: There is no prompt for operations that run with the client scheduler. If the client is running the scheduler and the client AUTOFSRENAME option is set to PROMPT, there is no prompt and the file space is not renamed. This allows a client session to run unattended. The prompt appears during the next interactive session on the client.
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 |
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.
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.
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.
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.
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.
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.
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.
The server manages a Unicode-enabled client and its file spaces as follows:
When a client performs a selective backup of a file or directory and the original file space is renamed, the new Unicode-enabled file space will contain only the file or directory specified for that backup operation. All other directories and files are backed up on the next full incremental backup.
If a client needs to restore a file before the next full incremental backup, the client can perform a restore from the renamed file space instead of the new Unicode-enabled file space. For example:
Refer to the Using the Backup-Archive Client publication for more information.
This section gives one possible sequence for migrating clients. Assumptions for this scenario are:
The following is a possible migration process:
update node file* autofsrename=yesThis 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.
update node a* autofsrename=yes
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.
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.
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.
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.
You can display file space information to:
You display file space information by identifying the client node name and file space name.
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.
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.
Administrators may want to delete a file space when:
The authority to delete backed up or archived files from server storage is set when a client node is registered. See Accepting Default Closed Registration or Enabling Open Registration for information on allowing users to delete files in storage pools.
For example, client node PEASE no longer needs archived files in file space /home/pease/dir2. However, he does not have the authority to delete those files. You can delete them by entering:
delete filespace pease /home/pease/dir2 type=archive
You must delete a user's files from storage pools before you can remove a client node. For example, to delete all file spaces belonging to client node ID DEBBYG, enter:
delete filespace debbyg * type=any
For client nodes that support multiple users, such as UNIX, a file owner name is associated with each file on the server. The owner name is the user ID of the operating system, such as the UNIX user ID. When you delete a file space belonging to a specific owner, only files that have the specified owner name in the file space are deleted.
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.