HW upgrade from DDS2 to DDS3

[Nis T. Jorgensen]

Hi,

We have just replaced our DDS2 with DDS3 tape drives, because our database exceeded 8GB. However, it seems that we can still only put 8GB on the tapes.

Are there any patches that we need to add as well?

The system is 9000/871/D370 HP-UX 11.00

Thanks.

BR
Jorgensen

[Peter Godron]

Hi,
have you got the correct drivers for your tape. Which device file are you using ?
See what's available in /dev/rmt .

[Pete Randall]

You need to switch media from DDS-2 to DDS-3.

http://www.hp.com/products1/storage/products/storagemedia/tape_dds/index.html


Pete

[Nis T. Jorgensen]

We're using /dev/rmt/0m, which was created with the insf command right after the HW replacement, but maybe it was not done correctly. Can you tell how it should be done?

Thanks.

BR
Nis

[Pete Randall]

No, your device file is just fine. The DDS-2 tape cartridge, however, only has a capacity of 8GB, no matter which type of drive you use it in. You need to switch media.


Pete

[Arunkumar.B]

Hi ,


Your old drive now will sense as no_hw in the ioscan ..

#rmsf -H of ur old drive

#insf -H of ur new drive

u will have to use DDS-3 Catridge then only u can take backup more than 8GB.


With Cheers
Arunkumar.B

[Peter Godron]

Hi,
are you using DDS3 tapes ?

[Nis T. Jorgensen]

Yes, we are using DD3 tapes.

root@smp6b:/dev/rmt> ioscan -fnCtape
Class I H/W Path Driver S/W State H/W Type Description
=====================================================================
tape 0 8/16/5.0.0 stape CLAIMED DEVICE HP C1537A
/dev/rmt/0m /dev/rmt/0mnb /dev/rmt/c2t0d0BESTn /dev/rmt/c2t0d0DDSb
/dev/rmt/0mb /dev/rmt/c2t0d0BEST /dev/rmt/c2t0d0BESTnb /dev/rmt/c2t0d0DDSn
/dev/rmt/0mn /dev/rmt/c2t0d0BESTb /dev/rmt/c2t0d0DDS /dev/rmt/c2t0d0DDSnb
root@smp6b:/dev/rmt> ll
total 0
crw-rw-rw- 2 bin sms 205 0x020000 Jul 15 23:14 0m
crw-rw-rw- 2 bin sms 205 0x020080 Dec 6 2000 0mb
crw-rw-rw- 2 bin sms 205 0x020040 Oct 26 2005 0mn
crw-rw-rw- 2 bin sms 205 0x0200c0 Dec 6 2000 0mnb
crw-rw-rw- 2 bin sms 205 0x020000 Jul 15 23:14 c2t0d0BEST
crw-rw-rw- 2 bin sms 205 0x020080 Dec 6 2000 c2t0d0BESTb
crw-rw-rw- 2 bin sms 205 0x020040 Oct 26 2005 c2t0d0BESTn
crw-rw-rw- 2 bin sms 205 0x0200c0 Dec 6 2000 c2t0d0BESTnb
crw-rw---- 1 bin sms 205 0x020001 Dec 6 2000 c2t0d0DDS
crw-rw---- 1 bin sms 205 0x020081 Dec 6 2000 c2t0d0DDSb
crw-rw---- 1 bin sms 205 0x020041 Dec 6 2000 c2t0d0DDSn
crw-rw---- 1 bin sms 205 0x0200c1 Dec 6 2000 c2t0d0DDSnb
crw-rw---- 1 bin sms 205 0xfffffe Dec 6 2000 stape_config

Does this look right?

[Jaime Bolanos Rojas.]

Nis,

It looks just about right for me, to be on the safe side just do a backup test of whatever you want and then recover it, exercise that you should do on a regular basis with your production backups, just to make sure they are always going to work in the event of failure.

Regards,

Jaime.

[Peter Godron]

Ok,
the obvious question "how long is ther tape"?
My 125m DDS3 says 12Gb native / 24 compressed
So if your tape is <= 120m it may only allow 8 Gb native. Have a look at the paper insert in the tape box.

[DCE]

Before you did the insf, did you perform a rmsf to remove the DDS2 drive files?

[Steve Lewis]

The other question is this:

How are you backing up the data and does that backup mechanism have the tape size defined?

Some backup mechanisms may have a tape size configured, so the backup software would request another tape after that amount of data had been sent, regardless of the drive type. You would have to reconfigure the tape size then try again.

[Nis T. Jorgensen]

1. Our tapes are 125m 12/24GB as well.

2. About the rmsf: is that important, because we did not do it, but device files look ok.

3. Basically the backup is just doing tar cvf /dev/rmt/0m ..., so it is not restricting itself to a certain size.

Here is what it is doing:

echo "`date` Sending backup directories to $BACKUP_DRIVE" >> $LOG
$TAR $(echo `echo $ONLINE_BACKUP_DIRS | tr -d "[\012]" | tr ";" "[\012*]" | while read line;do
echo $line | cut -f2 -d","
done
echo "$ONLINE_BACKUP_DEFAULT"
echo "$ONLINE_BACKUP_ARCH/*.arc"
if [ -n "$ONLINE_OPTIONAL_DIRS" ];then echo "$ONLINE_OPTIONAL_DIRS";fi
echo "$LOG"` | tr "[:space:]" "[\012*]" | sed "s+/$++g" | sort | uniq )

ERRORCODE=$?
if [ $ERRORCODE -ne 0 ];then
echo "`date` command "$TAR" exited with error code $ERRORCODE" >> $LOG
Abnormal_termination
fi
echo "`date` Sent backup directories to $BACKUP_DRIVE" >> $LOG

Where:

TAR="tar -cv"

It always ends up in the Abnormal_termination branch. Can anyone see any mistakes in the code?


BR
Nis

[Peter Nikitka]

Hi,

- what is the error message you get from your tar command?
- how many directories does the tar command get as parameters? Maybe the arglist gets too long?
- I do not think, you need a construct like
echo `echo ...` but that's another road...

Did you try to send plain data to your DAT-tape without using your script?

Look for a (perhaps better rather quiet) filesystem of size ~12GB and try to put that to your tape.

mfG Peter

[DCE]

Yesm the rmsf is important (rmsf -H hardware path)

The insf sometimes gets confused if there is an existing device file and will not actually create a new one.

You are best off if you completely remove the old device files (assuming you actually physically replaced the DDS2 with the DDS3)

This will allow the insf to create the correct files.

[Nis T. Jorgensen]

1.The error message we get when trying to read from the tape is this:

tar tv
...
rwxrwxr-x 101/101 0 Jul 24 00:00 2006 /u07/backup/
rwxr-xr-x 0/0 0 Dec 6 16:19 2000 /u07/backup/lost+found/
rw-r----- 101/101 524296192 Jul 23 23:37 2006 /u07/backup/system01.dbf
rw-r----- 101/101 419438592 Jul 23 23:40 2006 /u07/backup/rbssms02.dbf
Tar: tape error (6)

The log file from the backup program shows this:

Mon Jul 24 00:11:30 METDST 2006 Sending backup directories to /dev/rmt/0m
Mon Jul 24 02:23:18 METDST 2006 command tar -cv exited with error code 5
Mon Jul 24 02:23:21 METDST 2006 All tablespaces set to NORMAL during Abnormal_termination

2. It is only 6 directories that we are backing up, so it should not be too many directories. The amount of files is also low (<50).

3. It is possible to add and extract files to/from the tape without using the backup program, but I have not tried with 12GB (yet).

Are you recommending us to delete and recreate the device file even though it has a date from the time of HW replacement and the tape drive is working normally for small fileS?


BR
Nis

[Peter Nikitka]

Hi,

besides all testing, I recommend NOT to use absolute pathnames for tar-Backups. Restoring for testing purposes will be quite difficult without interfering with the production data.

mfG Peter