04-25-2011 06:16 PM
Recently, I attempted to restore the lib64 directory to a SuSE Linux client. Only when the restore had completed did I notice that several of the restored files were empty. Some of the empty files were:
/lib64/power5/libc-2.4.so, /lib64/power5/libpthread.so.o, /lib64/power5/libc.so.6, /lib64/power5/librt.so.1.
It turns out that these files, along with the others that were empty, are files with multiple links. That is to say that they share an inode number with similarly named files in another directory. The files in the other directories were fully restored.
Can anyone explain this behavior and tell me how to avoid it.
Configuration:
Backup Server: RHEL Server release 5.3
Client: SuSE Linux 10.2
Netbackup: Version 7.0 Buildnumber 20100104a
Netbackup Client: netBackup-IBMpSeriesSuSE 2.6.7.0
Thanks in advance
aquinlan
Solved! Go to Solution.
04-26-2011 01:17 AM
What did you choose in the restore screen w.r.t. hard link restores? (default is Rename hard links)
The way that hard links are backed up and restored is discussed in Administrator's Guide for UNIX,Linux, I http://www.symantec.com/docs/TECH127081
See p. 604 onwards as well as these TN's: http://www.symantec.com/docs/HOWTO33683 & http://www.symantec.com/docs/TECH10897
Also see this discussion: https://www-secure.symantec.com/connect/forums/hardlinks-are-not-restored-solaris-nbu-70
04-26-2011 01:17 AM
What did you choose in the restore screen w.r.t. hard link restores? (default is Rename hard links)
The way that hard links are backed up and restored is discussed in Administrator's Guide for UNIX,Linux, I http://www.symantec.com/docs/TECH127081
See p. 604 onwards as well as these TN's: http://www.symantec.com/docs/HOWTO33683 & http://www.symantec.com/docs/TECH10897
Also see this discussion: https://www-secure.symantec.com/connect/forums/hardlinks-are-not-restored-solaris-nbu-70