This section provides information on how SMS restores data. For more information about options supported during a restore, see the respective backup application documentation.
During a restore session, the backup engine reads the backup storage media, and the Target Service Agent (TSA) compares the media data set to the existing hard disk data set. The Target Service Agent evaluates each data set according to the following criteria:
Is this data set a subset of what is being restored?
Is this data set found on the hard disk?
Which parts of the data set are subject to restoring?
Is this data set a parent or a child, and is the Overwrite parameter set to Yes or No?
If the parameters for a child are set to Overwrite Only if Newer, does the backup copy have a more recent date than the existing copy?
NOTE:When machine is running, system libraries cannot be restored because smdr uses dynamically loaded libraries from /lib folder for restoration.
The file system backup contains the trustee or owner/group names for files and directories that were backed up. On restoration these names are used to map them back to the corresponding file system object IDs.
If the name-to-ID mapping is unavailable for any reason then the file is restored with the default connection ID. To ensure that the restoration preserves all ID information, update the relevant ID store (eDirectory or the user data base) on the system before you attempt the restore operation.
SMS now restores Active Directory trustees that were backed up. Ensure that the NSS volumes are AD enabled to restore the AD trustees.
If the volumes are not AD-enabled, then the files are successfully restored but the owner, user quota, and trustee information of the Active Directory user is not restored.
On restoring an NCP POSIX volume, the NSS user must be LUM-enabled to preserve the user’s ID.
Restoring an open file is not supported.
Restoring a file fails when a file with same name and extension already exists on the target and is used by some process or is in open state.