ADSM-L

[ADSM-L] Solaris restore problem

2007-07-16 16:26:09
Subject: [ADSM-L] Solaris restore problem
From: "Colwell, William F." <bcolwell AT DRAPER DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 16 Jul 2007 16:14:43 -0400
Hi,
 
one of my Solaris admins had to restore the boot disk recently.  It
didn't
go well!  Everything was restore eventually but it took a long time
because
the mount points of symbolic links were never backed up.  He had
to make them manually and restart the restore. The client os is 
Solaris 8, TSM client is 5160.  (My TSM server is on Solaris 9, level
5343).
 
I see a feature added at the 522 level called
'include.attribute.symlink'.
My question for anyone supporting Solaris is did you have this problem
and did 'include.attribute.symlink' fix it?
 
Thanks,
 
Bill Colwell
Draper Lab
 
Here is the admins note to me --
 
We have a Solaris 8 machine with the following filesystems:
 
# df -k
Filesystem            kbytes    used   avail capacity  Mounted on
/dev/dsk/c0t0d0s0    4131866 3423633  666915    84%    /
/proc                      0       0       0     0%    /proc
mnttab                     0       0       0     0%    /etc/mnttab
fd                         0       0       0     0%    /dev/fd
/dev/dsk/c0t0d0s5    11114920 7211849 3791922    66%    /var
swap                 207058792      40 207058752     1%    /var/run
swap                 207902688  843936 207058752     1%    /tmp
/dev/md/dsk/d3       246393677 117406778 126522963    49%    /vsmodels
/dev/md/dsk/d4       246393677 60366051 183563690    25%    /vstools
/dev/md/dsk/d5       702176891 612652932 82502191    89%    /home
gbc:/vol/vol1/tools  250524060 230791752 19732308    93%    /nfs/tools
fs1:/export/pub/SunOS-5.8-sparc
       390523840 211332012 179191828    55%    /nfs/pub
 
We lost the boot disk (c0t0d0) and had to restore the / and /var
filesystems 
from TSM backups (by attaching the replacement disk to another machine 
and performing a cross-restore).  But all of the filesystems listed
above 
(except for / itself) are mounted on empty directories (mount points) 
in either / or /var.  But, because TSM backs up each filesystem as a 
separate "filespace", and because it does not back up explicitly
excluded 
filesystems (/tmp, /var/run), NFS filesystems (/nfs/*), or special 
system "filesystems" (/proc, /etc/mnttab, /dev/fd) at all, the empty 
directories that serve as the mount points do not get backed up as part
of 
the parent filespace backup.  Therefore, when one does a full restore of

any filesystem, it is necessary to manually re-create all of the mount
points 
for anything that mounts within it (not something one wants to have to
remember 
to do when one has been up all night waiting for the restore to
complete, with 
angry users clamoring to get on!).
 
Since TSM is smart enough to determine what to exclude (either
explicitly 
or implicitly) and what is a separate filespace, it ought to be clever 
enough to put into the backup for any filespace all of the empty
directories 
that will be necessary to mount the things that were excluded or backed
up 
separately.

<Prev in Thread] Current Thread [Next in Thread>