hi, on my sol9 box i create my backup using the below command:

/usr/sbin/ufsdump 0uf /dev/rmt/0n /u1
/usr/sbin/ufsdump 0uf /dev/rmt/0n /u2
/usr/sbin/ufsdump 0uf /dev/rmt/0n /u3
/usr/sbin/ufsdump 0uf /dev/rmt/0n /u4

now on the new sol10 box, to restore i use this commands:

cd /u1
/usr/sbin/ufsrestore rfsvy /dev/rmt/0 1
rm /u1/restoresymtable

cd /u2
/usr/sbin/ufsrestore rfsvy /dev/rmt/0 2
rm /u2/restoresymtable

cd /u3
/usr/sbin/ufsrestore rfsvy /dev/rmt/0 3
rm /u3/restoresymtable

cd /u4
/usr/sbin/ufsrestore rfsvy /dev/rmt/0 4
rm /u4/restoresymtable

the reason i do the above restore commands like that is because i don't have enough space plus ufsrestore only does a relative restore therefore i want it to change to the actual destination directory before restoring.

the directories have different sizes:

/u1 - 35GB
/u2 - 48GB
/u3 - 97GB
/u4 - 150GB

/u1 contains the Oracle binary executables (and maybe some other Oracle related files) while the other directories contain data.

my concern is, why is /u1 taking so long to restore? in fact, /u4 restored in less than 30 minutes while /u1 is taking far longer than that! am i using the wrong restore options that is causing this?

There is no particular reason for /u1 to take much more time than the others according to the information you posted. You should investigate deeper (logs, truss, ...) to understand what ufsdump is precisely doing during this time.

hello,

i figured out the problem last Friday. it was due to a bad superblock (bad sector in doze speak). this causes the restore to slow down dramatically on the filesystem in question.

so i nuked "/u1" filesystem and did a newfs on it.

restore of 35GB took only an hour.