Considerations for migrating between processor architectures x32 and x64

When migrating between the Tivoli® Storage Manager processor architectures (x32 and x64), there are some items that you need to consider for a successful migration from one architecture to another.

Consider the following items when migrating from one processor architecture to another:

• The restore of DFS links backed up from 32-bit Windows environments to 64-bit Windows environments, is not supported.
• The restore of DFS links backed up from 64-bit Windows environments to 32-bit Windows environments, is not supported.
• System state data is incompatible between different processor architectures. Therefore, when migrating client data between different processor architectures, avoid backing up the system state data from one architecture into the same file spaces containing the system state data from another architecture. To avoid commingling the data, you can do either of the following before the migration:
  • Ask your Tivoli Storage Manager administrator to rename the existing system state file spaces. Once the migration is complete and you have new backups of the system state data, your Tivoli Storage Manager administrator can delete the renamed file spaces. The file spaces to rename include one or more of the following:
    • SYSTEM STATE
    • SYSTEM SERVICES
    • ASR

    Ask your Tivoli Storage Manager administrator to delete the existing file spaces for your node.

• Renamed file spaces remain on the server and managed as stabilized file spaces. These file spaces contain all the original data, which can still be restored until the file spaces are deleted. You can find additional information in the IBM Tivoli Storage Manager for Windows Administrator's Guide.
• When an existing file space is renamed during Unicode conversion, any access rules defined for the file space remain applicable to the original file space. New access rules must be defined to apply to the new Unicode file space, if necessary.
• When backing up files to a file space that is not Unicode-enabled, the Unicode-enabled client skips the files and directories with names containing characters from a code page other than the current locale.
• If files and directories with names containing characters from a code page other than the current locale were previously backed up with a client that was not Unicode-enabled, Tivoli Storage Manager expires them in the file space that is not Unicode-enabled. However, the Unicode-enabled client can back up or archive these files to a Unicode-enabled file space.
• When migrating from a client that is not Unicode-enabled to a Unicode client, file names with double-byte characters mixed with single-byte characters might be restored in mixed single-byte character set (SBCS) format. This is only a display issue.
• When a client performs a selective backup of an object and the original file space is renamed, the new Unicode-enabled file space contains only that object. Tivoli Storage Manager backs up all other directories and file spaces during the next full incremental backup.
• The Unicode-enabled client has a file and directory name size limitation of 504 bytes. Depending on the Unicode characters (2-byte, 3-byte, or 4-byte) used, this translates to a maximum of 126 to 252 characters.