Restore Data - Unix File System

Topics | How To | Full System Restore | Related Topics

Overview

Restore Considerations for this Agent

Maximum Filename Length for Unix File System iDataAgent Restores

Restore Unix Raw Devices

Restore VMware Virtual Machines

Restore VMware ESX Server 3.x Virtual Machine Data

Restore Macintosh File System

Restore Data to Trusted Solaris 10 Systems

Restore Hard Links

Restore Destinations

In-Place Restore
Out-of-Place Restore
Cross-Platform Restores
Restore to Network Drive/NFS-Mounted File System
Restore Data Using a Map File

Overview

The following page describes the agent-specific restore options. Additional restore options are accessible from the Related Topics menu.

Each Unix File System iDataAgent except for the IRIX File System iDataAgent supports data recovery operations for the appropriate Unix File System (UFS) data. In some cases, operations for some other File System data (e.g., CD-ROM File System [cdfs]) may be also supported. Also, some iDataAgents can recover additional file systems. For more information, see File Systems supported by the Unix File System iDataAgents.

In addition, depending on the specific Unix File System iDataAgent(s) and perhaps particular scenarios, data recovery support may or may not be available for the following items, among others:

Access Control Lists (ACLs)
Quota files
Raw device files

See Effect of Data Types on Restores by Unix File System iDataAgents for more information.

For the Unix File System iDataAgents, restore operations can be performed from the client, iDataAgent and backup set levels in the CommCell Browser.

When the root file system is lost, a full system restore is required. See the following as appropriate for more information:

To recover a VMware ESX Server using the Linux File System iDataAgent, see the following for more information:

For some Unix platforms, to recover a system that has defective components without having to reinstall operating system files and other file types, see the following as appropriate for more information:

Restore Considerations for this Agent

Try to avoid the unconditional overwrite of the root directory on a live file system. This is a mechanism that allows an unconditional overwrite of open files in the root directory (/) on a live file system. Performing such a restore can result in an inconsistent system that may also fail to boot. Use this option AT YOUR OWN RISK.

You can restore Unix File System data to any Unix client computer regardless of the specific Unix operating system that is installed on the client. For example, you can restore data backed up from a Solaris client to a Linux client. You can also restore to any Unix client.

When restoring any Unix File System data, keep the following in mind:

The iDataAgent runs as root on Unix systems.
Restored data retains its original permissions. Permissions are restored first and then ACLs are restored. However, ACLs cannot be restored to any directory that has the "sticky bit" on.
For the Unix File System iDataAgents, if you back up data contents including hard links with registry key HLINK set to Y and the appropriate hard link updates applied, and if a non-head hard link is removed between the scan and backup phases of the backup job, and if you then perform a browse and restore on the data contents, the hard link will not be displayed, and you will not be able to restore the link using this restore method. However, you will be able to restore the hard link using Restore by Jobs. See the Service Pack documentation for more information on hard link updates.
The number of entries in a single FAT32 directory cannot exceed 32,767. Consequently, you cannot restore the full contents of a Unix directory that contains more than 32,767 files to a single Unix FAT32 directory.
When restoring files with holes, the null blocks that form the hole may not be in the same location in the file relative to the data. The file size is not changed, but the number of disk blocks may change.
Restore operations on files that include the "[]" character sequence and/or the "\" character fail when restored without browsing. In order to restore these files via a browse operation, the directory that contains these files, or a higher level directory, must be selected in the browse window as content to restore. For example, if there is a file named file[]name in the /opt directory, then you must select the /opt directory or any directory that contains /opt for restore. If you select only the file, the restore will fail.
When restoring a default subclient after a full backup, the Latest Backup Data dialog window incorrectly displays top-level directories for any user-defined subclients that have not been backed up. Attempts to restore data from user-defined subclients that have not been backed up will fail.
If you do a framed browse (i.e., select both a begin and end date/time for the browse) and select the entire resulting data tree for restore by selecting the top-most (or root) node, an erroneous error message is displayed stating that the restore operation failed. Restores under these circumstances are successful regardless of the error message. To avoid this error message, select the data to be restored from the next-to-highest level in the tree.
Access Control List (ACL) data of files is not restored to directories with the sticky bit on. When restoring files to /tmp or any other directory that has the sticky bit on, the files are restored, and the system indicates that the restore is successful. However, the ACL data of the restored files is invalid.
The Tru64 iDataAgent on the Tru64 OSF1 Release 5.1B-3 platform cannot restore Access Control Lists (ACLs).
The names of files (including the path) to be restored by any Unix File System iDataAgent except the AIX File System iDataAgent cannot contain more than 1024 characters. For the AIX File System iDataAgent, the names of such files (including the path) cannot contain more than 1023 characters. However, an out-of-place restore that is run for a file whose name is within the character limit will fail if the resulting directory path to which the file is restored exceeds this limit.
For the Tru64 File System iDataAgent, avoid performing in-place and out-of-place restores of quota files. The contents of quota files (/quota.user and /quota.group) that are restored in place differ from the contents of these files before they were backed up. Also, it is possible that the contents of out-of-place restored quota files may differ from the contents of these files before they were backed up. Therefore, if you do restore these files either in place or out of place, do not use the files to generate quotas.
You can restore potential or actual holes in potential or actual sparse files as genuine holes using the OptimizeRunLengths registry key. Also, with or without this key, you can restore such items "flat".
Do not set a quota for an object (such as a volume, directory, or user) that is lower than the amount already used. Doing so may cause improper results for data protection or recovery operations.
An advanced restore option allows you to filter out mount points that are part of the backup data during the file system restore. This is useful in cases where you did not mount all the mount points and do not want to fill up the holding file system during the restore. Using this option will ensure that data belonging only to the restoring file system will be restored.

When restoring any Unix File System data other than HP-UX File System data, keep the following in mind:

Attempting to restore a running executable may cause the executable to crash and core dump.
Restoring a full file system from "/" may crash your system.

When restoring any Solaris File System data, keep the following in mind:

The sUFSRESTORE x registry key enables or disables ufsrestore. If ufsrestore is disabled at restore time, then clRestore will leave the .ufsdump file on disk for the manual use of ufsrestore.

Finally, see Effect of Data Types on Restores by Unix File System iDataAgents for more information.

Maximum Filename Length for Unix File System iDataAgent Restores

The names of files (including the path) to be restored by any Unix File System iDataAgent except the AIX File System iDataAgent cannot contain more than 1024 characters. For the AIX File System iDataAgent, the names of such files (including the path) cannot contain more than 1023 characters.

Restore Unix Raw Devices

The AIX, HP-UX, Linux and Solaris iDataAgents allow you to restore raw device files, including block and character, for their respective file systems.

Raw devices can be restored either in place or out of place. Also, best performance can be obtained using the character device.

Restore VMware Virtual Machines

The individual guest operating systems of the Virtual Machines running under the VMware ESX Server Can be restored using the appropriate iDataAgent. These operating systems can be Unix operating systems as well as other operating system types (e.g., Windows, NetWare, etc.) Also, you can use Command Line Interface to perform restores. For more information and procedures, see Restore a VMware ESX Server 2.5.x Virtual Machine.

Restore VMware ESX Server 3.x Virtual Machine Data

For a VMware ESX Server using Consolidated Backup, you can restore individual files backed up from a Virtual Machine. Based on the particular type of backup you performed (see Back up a VMware ESX Server 3.x Virtual Machine) select one of the following:

To restore files backed up from a VMware Virtual Machine using the ProxyHost iDataAgent, see Restore Data - Proxyhost and select the appropriate VMware Virtual Machine as the destination when performing the restore. The ProxyHost iDataAgent will correctly map the data in the Browse, to the original drive and location on the Virtual Machine from which the data was originally backed up.
To restore files backed up from a VMware Virtual Machine using the Windows File System iDataAgent, see Restore Data - Windows File Systems and select the appropriate VMware Virtual Machine as the destination when performing the restore.

In addition, you can restore a Disk Image for a VMware Virtual Machine which was backed up using VMware Consolidated Backup, whether the backup was performed from a VCB Proxy Server, or from the Service Console. For more information and procedures, see Restore a VMware ESX Server 3.x Virtual Machine Disk Image.

Restore Macintosh File System

You can restore MAC File System data to any Unix client computer regardless of the specific Unix operating system that is installed on the client. For example, you can restore data backed up from a MAC client to a Linux, AIX or other Unix client.

You can restore AppleDouble-encoded Macintosh files that contain resource fork data to a Unix File System. Ensure that the Recover Apple Resource Fork Data option is selected in the Browse/Recovery Option dialog box from the Control Panel and in the Advanced Restore Options dialog box for your iDataAgent before you run a restore of this data.

Restore Data to Trusted Solaris 10 Systems

You can control restoring data to zones on Trusted Solaris 10 systems by using the Enforce Label Checking on Trusted Solaris option in the Advanced Restore Options dialog box. This is useful if the data should be included only in a single zone (e.g., a "restricted" zone) or in multiple specified zones and should therefore be available only to authorized users.

Restore Hard Links

Hard links that have been backed up with registry key HLINK set to Y and the appropriate hard link updates applied can be restored using Browse and Restore or Restore by Jobs. This includes hard links that are missing before the restore.

See the Service Pack documentation for more information on hard link updates.

Browse and Restore can be used to restore missing hard links as part of a link group. To restore hard links as part of a link group, you must select the Unconditional Overwrite option in the Restore Options (General) dialog box.

When you use Browse and Restore to restore hard links as part of a link group, the following happens:

All hard links being restored are linked to the first file restored
First restored file will use the same link group if a file with the same path name exists in the file system
First file will use a new inode and create a new link group if a file with the same path name does not exist in the file system
Unconditional overwrite is used during the restore of the first file

The first file is the first one selected in the Browse windows or the first one that it is backed up.

Missing hard links that are restored using Restore by Jobs are linked together in their own link group (that is, in a link group separate from that for files that are not missing).

Restore Destinations

By default, the Unix File System iDataAgent restores data to the client computer from which it originated; this is referred to as an in-place restore. You can also restore the data to another Client computer in the CommCell. Keep in mind the following considerations when performing such restores:

The destination client must reside in the same CommCell as the client whose data was backed up.
Note that when you perform restores other than in-place restores, the restored data assumes the rights (i.e., permissions) of the parent directory.

Even if the file name itself is within the character limit, an out-of-place restore will fail if the resulting directory path to which the file is restored exceeds the character limit.

The following section enumerates the types of restore destinations that are supported by the Unix File System iDataAgent. See Restore/Recover/Retrieve Destinations - Support for a list of Agents supporting each restore destination type.

In-Place Restore

For in-place restores involving symbolic links to a raw device, all the symbolic links leading to the raw device as well as the parent directories of these symbolic links are restored. Also, the destination raw device node is created automatically, and the associated data is restored in that raw device.

An in-place restore to directories with existing (e.g., identical) files will invariably result in the job completing with errors. These errors are usually the result of "skipped" files. This condition will also occur when restoring data to "/", and it will potentially yield many errors. The results of the restore can be viewed using View Restore Items with options "successful", "failed", "skipped", and "all".

Same path/destination

Out-of-Place Restore

Keep in mind that out-of-place restore operations are also subject to the conditions described in Cross-Platform Restores.

Symbolic links to raw devices that are included in the target directory for an out-of-place restore are restored in place.

Cross-Platform Restores

Same Operating System - Different Version

Different Operating System

Restoring Unix Data to Windows, Macintosh and Other Unix Platforms

Restores of Unix data from a Unix machine to a Macintosh machine or vice-versa are not supported.

The Unix File System iDataAgent supports cross-machine restores for Unix data between any supported Unix platforms as well as between any of these platforms and Windows 2000/XP/Server 2003 and vice versa with some exceptions:

The HP-UX 11i iDataAgent does not restore ACLs from Itanium machines to PA-RISC machines of a different Unix platform and vice-versa.
ACL Settings Not Restored When Restoring: Unix UFS data other than Linux UFS data to a Windows or Unix platform, if ACLs are set on a file, those settings are not restored to either of these platforms.
When you restore any Unix File system data to a different Unix operating system or Windows platforms, ACLs may be lost if they are not compatible with different Unix operating system or Windows operating system.

When you backup the ACLs in the binary format in Solaris Sparc, you cannot restore them to Solaris x64. Similarly for HP-UX, when you backup the ACLs in the binary format in HPUX PARISC, you cannot restore them to HP IA64.

Restoring Unix to Windows Issues

Case-Sensitive Filenames Will Not Restore: Case-sensitive filenames will not restore from Unix to Windows because Windows does not maintain case-sensitive filenames. For example, if you are trying to restore files named "CASE_SENSITIVE" and "case_sensitive" from Unix to Windows, then whichever file is restored last will overwrite the first one that was restored.
Restoring a File with "\" in its Name:
If you restore a file with a "\" in its name (for example, file\.dat) to a Windows client computer, Windows interprets the "\" as a delimiter in the path name. The restore creates a folder on the Windows computer named file, which will contain a file named .dat. The contents of the files file\.dat and .dat are identical.
The following restores fail:
- Unix-specific device files such as block, character, or named pipe
- Unix files with the "?" character in their filename
- Windows allows 1024 characters for filenames, including the path. A filename, including the path, with more than 1024 (1023 for AIX) characters will not be restored from a Unix computer to a Windows computer.

Restoring Windows to Unix Issues

Cross-platform file system restores from Windows to Unix of files encrypted by the Windows operating system are not supported.

Restore to Network Drive/NFS-Mounted File System

Besides restoring data to a client computer�s local drive, you can also restore data to an NFS-mounted file system. (See Restore to Network Drive/NFS-Mounted File System for comprehensive information.)

Even if the file name itself is within the character limit, an out-of-place restore will fail if the resulting directory path to which the file is restored exceeds the character limit.