How do you ufsrestore the fast way?

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?

The restore time is influenced very much by the number of files to restore. So when you say, /u1 contains your oracle binaries, then I guess there are many small files to restore, whereas the other filesystems probably contain only a few database files which are restored much faster.

Also using the verbose option (v) could slow things down when many filenames have to be display to a slow terminal (console).

1 Like

i was thinking along the same lines but couldn't be sure. i listed the /u1 directory and sure enough, it contained lots of subdirectories which ufsrestore spent "make node" for 30 minutes. i see also lots of .htm files and such.

an update:

for the benefit of those who might be in the same situation. i found the cause of the slow restore. it is because the filesystem in question developed a bad superblock. so what i did is to nuke the filesystem and did a newfs on it. after that, restoring from tape of a 35GB data took only an hour.