You can merge imported client backup, archive, and space-managed
files into existing file spaces and automatically skip duplicate files
that might exist in the target file space on the server. Optionally,
you can have new file spaces created.
If you do not want to merge file spaces, see the topic on how duplicate
file spaces are managed.
By choosing to merge file spaces, you can restart a canceled import
operation because files that were previously imported can be skipped
in the subsequent import operation. This option is available when
you issue an EXPORT SERVER or EXPORT NODE command.
When you merge file spaces, the server performs versioning of the
imported objects by using the policy that is bound to the files. An
import operation might leave the target file space with more versions
than policy permits. Files are versioned to maintain the policy intent
for the files, especially when incremental export (by using the FROMDATE and FROMTIME parameters)
is used to maintain duplicate client file copies on two or more servers.
The following definitions show how the server merges imported files, based
on the type of object, when you specify MERGEFILESPACES=YES.
- Archive Objects
- If an archive object for the imported node that has the same TCP/IP
address, TCP/IP port, name, insert date, and description is found
to exist on the target server, the imported object is skipped. Otherwise,
the archive object is imported.
- Backup Objects
- If a backup object for the imported node has the same TCP/IP address,
TCP/IP port, insert date, and description as the imported backup object,
the imported object is skipped. When backup objects are merged into
existing file spaces, versioning is done according to policy just
as it occurs when backup objects are sent from the client during a
backup operation. Setting their insert dates to zero marks excessive
file versions for expiration.
Otherwise, the server completes
the following tasks:
- If the imported backup object has a more recent insert date than
an active version of an object on the target server with the same
node, file space, TCP/IP address, and TCP/IP port, then the imported
backup object becomes the new active copy, and the active copy on
the target server is made inactive. Tivoli® Storage
Manager expires
this inactive version according to the number of versions that are
allowed in policy.
- If the imported backup object has an earlier (less recent) insert
date than an active copy of an object on the target server with the
same node, file space, TCP/IP address, TCP/IP port, then the imported
backup object is inserted as an inactive version.
- If there are no active versions of an object with the same node,
file space, TCP/IP address, and TCP/IP port on the target server,
and the imported object has the same node, file space, TCP/IP address,
and TCP/IP port as the versions, then:
- An imported active object with a later insert date than the most
recent inactive copy becomes the active version of the file.
- An imported active object with an earlier insert date than the
most recent inactive copy is imported as an inactive version of the
file
- Any imported inactive objects are imported as other inactive versions
of the object.
- Space Managed Objects
- If the imported node's space-managed object has an external object
ID that is already on the target server, then the imported object
is skipped. Otherwise, the space-managed object is imported.
The number of objects that are imported and skipped is displayed
with the final statistics for the import operation.