I carried out just precisely this procedure for a client on Thursday of
last week, except on Solaris instead of SGI. I used the rename hard
links option, but not the rename soft links. Read up on the differences
between soft and hard links, and those choices should make sense.
Basically, hard links point to the actual data on disk, and soft links
point to a pathname. Since you'll be booting of the restored drive as
/... instead of /mnt/..., your softlinks, after the reboot, will point
to the correct location, assuming you haven't changed the layout of the
filesystem(s) as well.
dshauver AT laurustech DOT com
Charlene Osborn wrote:
>Due to a hardware failure of the worst kind, we lost
>both our root disk and our mirrored root disk on a fairly
>critical Sun machine this week. Thus forcing me to do what
>no backup admin really wants to do - installed two new
>disks and then installed enough Solaris, network information
>and NetBackup to allow me to restore from backups. All in
>all it worked, but with one snag I'd like to avoid 'next time'.
>I mounted the second disk that I was planning on restoring '/'
>to as /mnt, with plans to later make this the boot disk. When
>doing the restore I selected to 'restore to a different place'
>option. The question was whether or not to rename hard and soft
>links. Solaris makes use of hard links and we have many, many soft
>links. For the most part we use relative path names so it's not
>a problem, but the absolute path names are. If I don't rename
>we end up with links to '/mnt/.....'. If I do rename paths I get
>both complaints about files that don't exist (when trying to
>link to my minimal /) or complaints about trying to link
>across devices (for the hard links).
>I ended up going with the renaming links option and then using
>a 'find' to fix the links with absolute paths. My question (yes,
>there is one somewhere in here!) is there a better way to do
>this? How do most people handle links when they are doing
>restores? I know that Veritas has a product specifically for
>disaster recovery but it's not available for SGIs
>(our even more critical systems) so we haven't pursued it.
>Thanks in advance,
>Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu