Kbase 16319: probkup fails on OpenServer 5 using HP DDS tape drive
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
18/11/2008 |
|
Status: Verified
FACT(s) (Environment):
SCO OpenServer 5
SYMPTOM(s):
Progress backup (probkup) fails.
CRC check error reading backup block <block-num> (1147)
Restore failed. (1618)
DDS Tape Drive
CAUSE:
The Progress backup utility (probkup) fails to write to tape correctly on SCO OpenServer 5. The symptoms are that probkup writes to the tape normally but when you try to restore it, you will get output similar to the following:
# prorest test /dev/rStp1
This is a full backup of /usr2/tmp/sports.db.
This backup was taken Wed Oct 30 08:57:14 1996.
It will require a minimum of 230 blocks to restore.
CRC check error reading backup block 1 (1147)
CRC check error reading backup block 2 (1147)
CRC check error reading backup block 3 (1147)
Remove volume 1 from /dev/rStp1. (3761)
Please prepare volume 2 on /dev/rStp1, press enter when ready
Restore failed. (1618)
The cause of this looks like to be an incompatibility between the SCO tape driver and certain tape drives. So far the problem has been reported with HP DDS tape drives.
FIX:
Using a different tape drive works.
An example drive model that is known to produce this behaviour is HP C1533A 8GB DDS2 tape drive. However, at least this drive can be set up to work correctly by simply changing the block size of the drive from the default variable (0) to a fixed block size.
In our testing, setting the block size to a fixed value 512, 1024, 2048, 8192, 16384 or 32768 made the drive write the tape correctly. Use the "tape" command to change block size as follows:
tape -a 1024 setblk /dev/rStp1
This sets the block size of the tape device /dev/rStp1 to 1024.
Note that you need to run this command each time prior to the probkup
or prorest command.
This error ONLY occurs when using certain tape drives. In our
testing the OS configuration was the same "Generic SCSI1 / SCSI2
tape" and just by changing the tape drive to an IBM
(Archive) model cured the problem. The IBM drive had no problems
with probkup using variable block size.
(30-Nov-00) We found another possible solution with one customer who reported a dbdown after a system crash. They had previously set the block size to 1024, but when they tried to prorest they were getting the 1147 crc errors. Copying the backup from the tape using cat worked: we could prorest from the file we created on the system. Initially, we had tried copying with cpio, but prorest still terminated out with the 1147.