My original problem was:
>I have a Tru64 V5.0A system that ran LSM mirrored drives and the system
>failed. I have another Tru64 V5.0A system freshly installed on which I've
>connected one of the old drives and I'd like to mount the old /usr and
>/var partitions (AdvFS format) to recover data created since the last
>back-up.
I received helpful tips from several folks, but the best fit for my
specific problem came from DEC/Compaq/HP's Tim Mark:
>LSM only supports moving entire diskgroups between systems, not
>individual disks and/or volumes.
>
>For encapsulated partitions however there is a simple procure to
>"unencapsulate" the data and allow it to be accessed on another
>system. Please note that this is a one-way transition and that
>the disk cannot be brought back to the original system and used
>under LSM without a fair amount of reconfiguration.
>
>From the LSM side all one needs to do is:
>
>1. Make sure that LSM is not running on the new system.
Tim and I exchanged further messages to explain this to me. His
concern was that LSM would mount the moved drive which would prevent
the partition change from LSMpriv to AdvFS. I tried it both with and
without LSM installed and configured on the new system and it didn't
seem to matter either way since my new system had no prior knowledge
of the drive.
>2. Remark the partitions as in-use by AdvFS instead of
> the old LSM usage (LSMnoprv). For example:
>
> # disklabel -F -s /dev/rdisk/dsk3g AdvFS
> # disklabel -F -s /dev/rdisk/dsk3h AdvFS
>
>I will leave it to the AdvFS experts to recommend a procedure for
>bringing the domains back under AdvFS control but here is a procedure
>that has worked for me:
>
>3. Make the new domain directories:
>
> # mkdir /etc/fdmns/old_usr /etc/fdmns/old_var
>
>4. Create the device links
>
> # ln -s /dev/disk/dsk3g /etc/fdmns/old_usr/
> # ln -s /dev/disk/dsk3h /etc/fdmns/old_var/
These last two lines instead needed to be:
# ln -s /dev/disk/dsk3g /etc/fdmns/old_usr/usr
# ln -s /dev/disk/dsk3h /etc/fdmns/old_var/var
(see below for more on this.)
>5. Make the new mount points
>
> # mkdir /old_usr /old_var
>
>6. Mount the domains
>
> # mount old_usr#usr /old_usr
> # mount old_var#var /old_var
Even after all of this, I was still unable to mount the access points.
I got an error message indicating that the mount points did not contain
valid AdvFS volumes.
I was very reluctant to use anything that needed write access to the
drive for fear of corrupting it, but ultimately ended up running
/sbin/advfs/advscan to rebuild the mount point data in /etc/fdmns
(-r option) and to reconcile the drive's g & h partitions (-f option).
I suspect that this second step was the one that really mattered. I
suspect that manual creation of the directory entries probably would
have worked if I had done the advscan -f step, too.
One extra tidbit I discovered was that for the disk to mount, I HAD to
use the same names for the filesets as originally used. Specifically,
the advscan created entry for /etc/fdmns/domain_dsk3g/dsk3g had to be
modified to /etc/fdmns/domain_dsk3g/usr in order for it to mount.
When I tried to create similar entries on my own (as noted in Tim's
suggestion #4 above) before running advscan, it didn't work. advscan
cleaned up something additional and that appeared to be the key.
I was able to completely recover both the usr and var partitions off
of the drive once it mounted.
Thanks Tim Mark, Pat O'Brien (mitidata.com), and Mahendra Rajah (Univ
of Regina, Sask) who provided information and words of encouragement
and to this great list!
Greg
Received on Thu Jul 04 2002 - 17:44:28 NZST