![]() |
![]() |
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 |
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.
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.
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.
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.
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
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.
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.
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
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:
Tivoli Storage Manager does not automatically rename client file spaces when the client system upgrades to the Unicode-enabled Tivoli Storage Manager 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, Windows 2000, Windows 2002, Windows .NET, and Windows XP system at Tivoli Storage Manager Version 4.2.0 or higher.
Tivoli Storage Manager 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. Tivoli Storage Manager 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 Tivoli Storage Manager 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 Tivoli Storage Manager 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 22. 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, 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.
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 Tivoli Storage Manager 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 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.
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 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.
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.