Restrictions can affect planning and implementation. For
example, Tivoli® Storage
Manager applies
the replication rule for archive data to the data that was migrated
by the HSM for Windows client.
If you restore a file from the
Tivoli Storage
Manager target server,
and the file system is managed by
Tivoli Storage
Manager for Space Management, you must
not restore the file as a stub file. You must restore the complete
file. Use the
restoremigstate=no option to restore
the complete file. If you restore the file as a stub from the target
server, the following consequences can occur:
- You cannot recall the file from the Tivoli Storage
Manager source server
by using the Tivoli Storage
Manager for Space Management client.
- A Tivoli Storage
Manager for Space Management reconciliation
process that runs against the Tivoli Storage
Manager source server
expires the file. If the file is expired by a reconciliation process,
you can restore the complete file with the backup-archive client and
the restoremigstate=no option.
The following restrictions apply to node
replication:
- Store operations to a target replication server
- If a client node is configured for replication, you cannot back
up, archive, or migrate its data to the server that is the target
replication server for the replicated data that belongs to the node.
- Failover to a target replication server
- You can use automatic failover only with Tivoli Storage
Manager V7.1 servers
and clients. Only one failover server for each node can be used. The
failover server is always set to the last target server to which the
node was replicated. The client can recover data from the target replication
server, but it cannot store data during failover processing. Issue
the QUERY SESSION command to determine whether
a client node is in failover mode.
- The Tivoli Storage
Manager for Space Management and HSM
for Windows clients, however,
do not automatically fail over to the target server. You must manually
edit the dsm.sys file to connect to the target
server. Any secondary server information in the replservername stanza
and myreplicationserver option is ignored by
the Tivoli Storage
Manager for Space Management and
HSM for Windows clients.
- Client node definition on the target replication server
- If you plan to add a node for replication, the client node definition
cannot exist on the target replication server. If the client node
definition does exist on the target replication server, you must remove
or rename the node before replication can occur.
However, if the
data that belongs to a client node was exported from the source replication
server and imported on the target replication server, you do not have
to delete the client node definition on the target replication server.
To replicate, the data must be synchronized between the source and
target replication servers. Synchronization occurs during replication.
To
synchronize data, the data must be imported with the value of the DATES parameter
that is set to ABSOLUTE on the IMPORT NODE command.
- Import and export operations
- After initial replication, data that belongs to
a replicated client node cannot be imported to the target replication
server for replication. However, you can export the data that belongs
to the client node from the source replication server to other servers.
To export, you can use media or server-to-server virtual volumes.
Replication rules are not exported.
- Data migrated by the HSM for Windows client
- The Tivoli Storage
Manager for
HSM for Windows client provides
hierarchical storage management (HSM) for Windows NTFS file systems. When the HSM for Windows client stores data on
the Tivoli Storage
Manager server,
the data is stored as archive data, not as space-managed data.
During
replication processing, Tivoli Storage
Manager applies
the replication rule for archive data to the data that was migrated
by the HSM for Windows client.
For example, suppose that a backup-archive client has a file space
that contains two directories. The data in one directory is archived
to the Tivoli Storage
Manager server.
The data in the other directory is migrated by the HSM for Windows client, but it is stored
as archive data. Both sources of data are associated with the same
file space on the server.
If you set the file space replication
rule for archive data to ALL_DATA and the file-space replication rule
for space-managed data to NONE, the rule for space-managed data is
ignored during replication processing. All the data in the file space
is replicated to the target replication server according to the rule
for archive data.
- Objects that cannot be replicated
- The following objects cannot be replicated to a target replication
server:
- Replication rules
- Server node definitions
- Network-attached storage data in nonnative storage pools
- Client schedules
- Backup sets
Tips: - If you want to convert client nodes for store operations to a
target replication server, you can manually duplicate client schedules
that are on the source replication server.
- You can generate backup sets on the target replication server
for a replicated client node.
- Retention protection
- You cannot configure servers for replication on which archive
retention protection is enabled.
- Replication and file groups
- When you are replicating files from one server to another, it
is possible that some of the files that are being replicated belong
to a group of files that are managed as a single logical entity. If
a replication process ends without replicating all the files in a
group, client nodes are unable to restore, retrieve, or recall the
file group. When replication runs again, the source replication server
attempts to replicate the missing files.
- Renaming a node
- If a node is configured for replication, it cannot be renamed.
- Backing up a single client node to two source replication servers
- If you have been backing up, archiving, or migrating a client
node to two different servers, do not set up replication of the node
from both source replication servers to the same target replication
server. Replicating from two source servers might create different
versions of the same file on the target server. Replicating from two
source servers can cause unpredictable results when you restore, retrieve,
or recall the file.
- Password propagation to the target replication server
- When client node data is replicated for the first time, the source
server sends the node definition, including the password, to the target
replication server. During subsequent replications, if the node password
is updated, the source server attempts to send the updated password
to the target replication server.
Whether these attempts succeed
depends on the node authentication method and on the combination of
methods that are used on the source and target replication servers.
A conflict occurs if a node password is authenticated on the source
server by one server and on the target replication server by a different
server. Because authentication can happen on an LDAP (Lightweight
Directory Access Protocol) directory server or the Tivoli Storage
Manager server,
data can be lost. If this kind of dual authentication occurs, the
password is not updated during replication.
- Simultaneous-write function
- During replication processing, the simultaneous-write function
is disabled on the target replication server when you store data to
a primary storage pool that is enabled for data deduplication. Data
that is replicated consists of only files or extents of data that
do not exist on the target replication server.