After my big disaster, I'm restoring from tape on my Sun box. This is the second time I've used 'ufsrestore' with this DEC TZ88 SCSI DLT drive. The last time was for a migration from one box to another. Both the last time and this time, the restore has taken a hell of a lot longer than the backup does. The full nightly backup takes about 2-4 hours for 14 gigs of data. But when using 'ufsrestore -i' to restore 14 gigs it's taking more like 14-18 hours at a time. (I've had to do test restores so I have a few different cases with the data hovring between 12-14 gigs and the restore times between 14-18 hours) What I'm wondering is if there are any driver parameters or SCSI subsystem parameters I should be tuning for restores in order to get a faster restore time. Is it slow because I'm using 'ufsrestore'? Is it slow because I'm using 'ufsrestore' in interactive mode?
Restores slower than backups - Part of the explaination I don't totally agree with (an assumption that there is a backup server
) Data is sometimes read and then written to the backup tape from the same server. And writing to tape could be a blockage but otherwise his points are good.
Most local dump programs are implemented as multiple processes. There are several data readers feeding one tape writer process. You can usually write fast enough that the tape drive won't stop moving. (These multiple processes could be viewed as client/server 
Not what he meant I know...) He's right that file creation is slow. (Especially if you have directories) But it's enough that the tape drive will often stop and must be restarted. That contributes a lot to the slowness. For some reason, tape drives are much faster if you keep the tape moving. But I'm not a hardware guy so I don't know why this is.
OK. That makes a good deal of sense. I have to assume then that the backup program doesn't actually store the attributes with the file, but in a separate store of some kind. Especially in the case of a raw dump type utility. This would explain why, when my restore completed, I am prompted with a question asking if I want to restore owner:group attributes. So, my files are probably written from the tape to the drive with the owner:group set to the user who is running the restore (in my case 'root'). Afterwards, the final process runs through the restored files and then does a chown on each of them. Hehehe... I think there is also the distinct possibility that the tape drive I'm dealing with just has crappy performance in Solaris too.
Sounds like you did a sequential ufsdump - which is a lot faster than an interactive ufsrestore (Where the tape heads are jumping around more based on yor selection criteria (e.g add/extract)). During an Solaris interactive restore, you generally just select the file(s) you require restoring from the filesystem (e.g a config file like /etc/hosts), although you can just select (add) everything and carry on with the restore. (if you have selected a ufsrestore ivf, the verbose option will also slow things down)
For a simple clean backup, I usually take a complete UFS level 0 dump; something like this ...
to dump ...
mt -f /dev/rmt/0 rewind # rewind the tape
for i in `/ /var /opt /export/home /opt/{filesystem} /opt/{filesystem}`
do
ufsdump 0f /dev/rmt/0n $i
echo "Completed ufs dump level 0 of $i ... "
done
echo "backup completed ... "
mt -f /dev/rmt/0 rewind
mt -f /dev/rmt/0 offline # eject the tape
Then try restoring the whole filesystem as follows with a similar script/set of commands ...
use mt -f /dev/rmt/0 fsf or bsf to move to the markers on the tape and when your happy you have the correct filesystem, complete a ufsrestore 0f /dev/rmt/0n (no rewind) to your filesystem. Should be quicker?
If you want to be even more fancy (in terms of potentially dealing with less data to backup), you could take incremental backups, which means you will only have to backup data that has changed from the last ufsdump date. Restores can get a bit tricky and messy though.