Tape - Trying to Backup a T2000 Server to a Tape Drive Over a Network Using ufsdump

Asset ID:	1-72-1551084.1
Update Date:	2017-05-22
Keywords:

Solution Type Problem Resolution Sure

Solution 1551084.1 : Tape - Trying to Backup a T2000 Server to a Tape Drive Over a Network Using ufsdump

Applies to:

Sun StorageTek SL24 Tape Autoloader - Version All Versions and later
Sun StorageTek SL48 Tape Library - Version All Versions and later
Sun StorageTek L700e Tape Library - Version Not Applicable and later
Sun StorageTek SL500 Modular Library System - Version All Versions and later
Information in this document applies to any platform.
The server sees the sl24 perfectly fine. A backup using OSB was completed this morning for the Host server. The issue is when I try to do a ufsdump remotely to the sl24 through the host server.
-Developed after sl24 has been working and is still working but the ufsdump will not see the device.
-Yes the sl24 is initialized and in a ready state
-The server is an Oracle/SUN M4000 running Solaris 10

Symptoms

Trying to backup a T2000 server to a tape drive over a network using ufsdump.

When running the command to dump, get the following: Do not have anything in /dev/rmt. The SL24 is mounted at /dev/obt0 but it says there is no such device.

ufsdump 0ucf 172.25.206.240:/dev/scsi/changer/c3t500143801403874Fd1 /
DUMP: 172.25.206.240: Connection timed out
DUMP: Cannot connect to tape host `172.25.206.240'
DUMP: The ENTIRE dump is aborted.

ufsdump 0ucf 172.25.206.78:/dev/obt0 /
DUMP: permission denied
DUMP: Cannot connect to tape host `172.25.206.78'
DUMP: The ENTIRE dump is aborted.

==============================================

57 /etc % ufsdump 0ucf 172.25.206.78:/dev/obt0 /
DUMP: Date of this level 0 dump: Tue Apr 23 15:18:59 2013
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/rdsk/c0t1d0s0 (lrrpsf:/) to 172.25.206.78:/dev/obt0.
DUMP: Mapping (Pass I) [regular files]
DUMP: Mapping (Pass II) [directories]
DUMP: Writing 63 Kilobyte records
DUMP: Estimated 979826 blocks (478.43MB).
DUMP: Dumping (Pass III) [directories]
DUMP: write: No such device or address
DUMP: Write error 0 blocks into volume 1
DUMP: NEEDS ATTENTION: Do you want to restart?: ("yes" or "no") yes
DUMP: Change Volumes: Mount volume `#1' on `172.25.206.78:/dev/obt0'
DUMP: NEEDS ATTENTION: Is the new volume (#1) mounted on `172.25.206.78:/dev/obt0' and ready to go?: ("yes" or "no") yes
DUMP: Dumping (Pass III) [directories]
DUMP: write: No such device or address
DUMP: Write error 0 blocks into volume 1
DUMP: NEEDS ATTENTION: Do you want to restart?: ("yes" or "no") no
DUMP: The ENTIRE dump is aborted.

Cause

When OSB is installed it installs its own driver for the tape drives and thus disables the standard Solaris "ST" driver.
We believe ufsdump uses the standard ST driver so if it is disabled they won't be able to do anything with ufsdump and the drive.

Solution

This has to do with the "ST" driver. Once the customer installed OSB on that server OSB (Oracle Secure Backup) automatically disables the "ST" driver in Solaris.
Ufsdump requires the ST driver so that it can control the tape drive. So if the ST driver has been disabled then ufsdump will never work.
Their only option would be to un-install OSB from that server so that the ST driver will be enabled again and they can then use usfdump again.

Note: This issue can effect any library or tape drive since all tape drives use the ST driver on Solaris. Usually UFSDump is only used with the samller libraries / autoloaders.

Addditional info provided by Ryan Lucas

Attachments

This solution has no attachment