DOCUMENTATION: How NetBackup behaves with Hard Links when restoring hard-linked files on Unix Platforms

Article:TECH10897  |  Created: 2007-01-28  |  Updated: 2013-10-23  |  Article URL http://www.symantec.com/docs/TECH10897
Article Type
Technical Solution

Product(s)

Environment

Issue



DOCUMENTATION: How NetBackup behaves with Hard Links when restoring hard-linked files on Unix Platforms

Solution



Manual: NetBackup (tm) Users Guide for UNIX

Modification Type:  Addition

Modification:

For the following example, the original location of the affected files was /usr/bin. The find command was run with the following syntax (substituting an actual inode number for <inode_num>:

find /usr/bin -inum <inode_num>

The command returned the following file list:

# find /usr/bin -inum xxxx
/usr/bin/alias
/usr/bin/bg
/usr/bin/cd
/usr/bin/command
/usr/bin/fc
/usr/bin/fg
/usr/bin/getopts
/usr/bin/hash
/usr/bin/jobs
/usr/bin/kill
/usr/bin/read
/usr/bin/test
/usr/bin/type
/usr/bin/ulimit
/usr/bin/umask
/usr/bin/unalias
/usr/bin/wait


When a restore to an alternate location of the entire directory is initiated, NetBackup will restore all files and hard links appropriately:

# find /tmp/new/bin -inum <inode_num>

/tmp/new/alias
/tmp/new/bg
/tmp/new/cd
/tmp/new/command
/tmp/new/fc
/tmp/new/fg
/tmp/new/getopts
/tmp/new/hash
/tmp/new/jobs
/tmp/new/kill
/tmp/new/read
/tmp/new/test
/tmp/new/type
/tmp/new/ulimit
/tmp/new/umask
/tmp/new/unalias
/tmp/new/wait


NOTE  When restoring hard-linked files to any alternate location, Rename Hard Links must be selected in the Specify Alternate Path section. If this is not selected, NetBackup will only restore the first file alphabetically that it encounters; all other files will be a zero byte file.  The behavior is as designed with the base version of NetBackup and is used to conserve media.  When a filesystem with multiple hard links is encountered, NetBackup will backup the first file encountered alphabetically, every other file with the same inode will be backed up as a reference to that first file.  In the example used, a full copy of the first file /usr/bin/alias is backed up, all other files in the above list were simply backed up as a reference to the inode for /usr/bin/alias.  



When recovery of the files "unalias" and "wait" was attempted, NetBackup failed to recover the files. NetBackup will recover the directory structure, but as in this test of two files, there will be nothing in that directory:

# ls -al
total 32
drwxr-xr-x   2 root     root        117  May 10 14:27 .
drwxrwxrwt  22 root     sys         4061 May 10 14:29 ..

The restore log should be similar to the example below.


Restore started 05/10/2007 14:28:30

14:28:33 (68.xxx) Restore job id 68 will require 1 image.
14:28:33 (68.xxx) Media id CMH445 is needed for the restore.

14:28:45 (68.001) Restoring from image created Thu May 10 14:20:28 2007
14:28:46 (68.001) TAR STARTED
14:28:49 (68.001) INF - Waiting for positioning of media id CMH445 on server MEDIA for reading.
14:29:23 (68.001) INF - Beginning restore from server MEDIA to client CLIENT.
14:29:24 (68.001) /usr/bin/unalias
14:29:24 (68.001) Changed /usr/bin/unalias to /tmp/new1/unalias
14:29:24 (68.001) Changed link to /usr/bin/alias to /tmp/new1/alias
14:29:24 (68.001) Could not link /tmp/new1/unalias -> /tmp/new1/alias. Errno = 2: No such file or directory
14:29:24 (68.001) /usr/bin/wait
14:29:24 (68.001) Changed /usr/bin/wait to /tmp/new1/wait
14:29:24 (68.001) Changed link to /usr/bin/alias to /tmp/new1/alias
14:29:24 (68.001) Could not link /tmp/new1/wait -> /tmp/new1/alias. Errno = 2: No such file or directory
14:29:24 (68.001) INF - TAR EXITING WITH STATUS = 0
14:29:24 (68.001) INF - TAR RESTORED 0 OF 2 FILES SUCCESSFULLY
14:29:24 (68.001) INF - TAR KEPT 0 EXISTING FILES

14:29:25 (68.001) Status of restore from image created Thu May 10 14:20:28 2007= the restore failed to recover the requested files

14:29:27 (68.xxx) INF - Status = the restore failed to recover the requested files.


The "Could not link /tmp/new/bin/unalias --> /tmp/new/bin/alias: No such file or directory" in the example refers to the hard-linked file that NetBackup was trying to recover and the original file that NetBackup had as a reference for the inode number. In this case, the file was "alias." Even though the original file did exist on the system, hard links cannot span mount points and consequently, those files were not recovered.

But when the "alias" file is included, NetBackup will recover the three files correctly, with the hard link information intact:

# ls -ail
total 80
 18243812 drwxr-xr-x   2 root     root         304 May 10 14:34 .
  2957736 drwxrwxrwt  22 root     sys         4061 May 10 14:34 ..
 18528075 -r-xr-xr-x   3 root     bin          134 Jan 21  2005 alias
 18528075 -r-xr-xr-x   3 root     bin          134 Jan 21  2005 unalias
 18528075 -r-xr-xr-x   3 root     bin          134 Jan 21  2005 wait


The restore also shows that NetBackup was able to successfully convert the old hard link information over to the new directory structure.


Restore started 05/10/2007 14:33:14

14:33:17 (69.xxx) Restore job id 69 will require 1 image.
14:33:17 (69.xxx) Media id CMH445 is needed for the restore.

14:33:21 (69.001) Restoring from image created Thu May 10 14:20:28 2007
14:33:22 (69.001) TAR STARTED
14:33:25 (69.001) INF - Waiting for mount of media id CMH445 on server MEDIA for reading.
14:34:31 (69.001) INF - Waiting for positioning of media id CMH445 on server MEDIA for reading.
14:34:35 (69.001) INF - Beginning restore from server MEDIA to client CLIENT.
14:34:36 (69.001) /usr/bin/alias
14:34:36 (69.001) Changed /usr/bin/alias to /tmp/new1/alias
14:34:49 (69.001) /usr/bin/unalias
14:34:49 (69.001) Changed /usr/bin/unalias to /tmp/new1/unalias
14:34:49 (69.001) Changed link to /usr/bin/alias to /tmp/new1/alias
14:34:49 (69.001) /usr/bin/wait
14:34:49 (69.001) Changed /usr/bin/wait to /tmp/new1/wait
14:34:49 (69.001) Changed link to /usr/bin/alias to /tmp/new1/alias
14:34:49 (69.001) INF - TAR EXITING WITH STATUS = 0
14:34:49 (69.001) INF - TAR RESTORED 3 OF 3 FILES SUCCESSFULLY
14:34:49 (69.001) INF - TAR KEPT 0 EXISTING FILES

14:34:50 (69.001) Status of restore from image created Thu May 10 14:20:28 2007 = the requested operation was successfully completed

14:34:51 (69.xxx) INF - Status = the requested operation was successfully completed.


NetBackup will also recover all files correctly if the main hard-linked file is in place. For example, the file "wait" was removed:
# rm wait
# ls -ail
total 64
 18243812 drwxr-xr-x   2 root     root         243 May 10 14:45 .
  2957736 drwxrwxrwt  22 root     sys         4061 May 10 14:42 ..
 18528075 -r-xr-xr-x   2 root     bin          134 Jan 21  2005 alias
 18528075 -r-xr-xr-x   2 root     bin          134 Jan 21  2005 unalias
#
When recovery of wait was initiated, it was successful because the main hard-linked file was in place; in this case, the file was "alias."
# ls -ail
total 80
 18243812 drwxr-xr-x   2 root     root         304 May 10 14:34 .
  2957736 drwxrwxrwt  22 root     sys         4061 May 10 14:34 ..
 18528075 -r-xr-xr-x   3 root     bin          134 Jan 21  2005 alias
 18528075 -r-xr-xr-x   3 root     bin          134 Jan 21  2005 unalias
 18528075 -r-xr-xr-x   3 root     bin          134 Jan 21  2005 wait

When restoring to an alternate client, the behavior is the same as for a local client.





Legacy ID



236364


Article URL http://www.symantec.com/docs/TECH10897


Terms of use for this information are found in Legal Notices