/dev/rmt/0m and dds2 (4 or 8 gig?)

[Doug Schroeder]

I'm confused. I noticed that my 4gig of data
is causing my nightly fbackup to run into normal EOT. I presume this means I am not compressing my data?
Tape drive=1533a
Media=dds 120meter
device = /dev/rmt/0m
According to an HP chart online, the 1533a
should support 8gig with 120m media right?
The drive says dds2 right on the front.
According to my calculations, I am only getting 4 gig of data on each tape though.
When investigating through SAM's backup icon,
SAM identified my only available device as:

10/12/5.0.0 C1533A 4BG DDS Data Compression Tape Drive (DAT).

Now I'm even more confused. Do I need to do something really obvious in order to enabled compression?

Thanks,
Doug

[Doug Schroeder]

Also, the amber 'clean' LED flashed at the end of backups even if it didn't reach EOT.
I have tried several different cleaning tapes but the flashing amber lamp still appears and remains flashing until any new media is loaded. HP's online LED referenced didn't shed any light on this.

[Michael Francisco]

DDS2 standard is 4GB uncompressed. Typically the drives perform hardware compressions, but I don't use fbackup, so I don't know if there is something about fbackup that overrides hardware compression. I'm more concerned about your clean light problem...

If cleaning clears the amber light only until you start a new backup session, you probably need to call HP support to replace your tape drive (I have replaced at least five drives in the last year under hp maintenance); unlike DLT drives, DDS drives are supposed to be able to handle unnecessary cleaning, so the trick is to clean them often.

It is possible that it is just a coincidence that you are only backing up 4GB and that the tape drive just quits after 4GB due to the clean drive head problem. If you are under HP hardware support, they'll replace it (after you get lectured on how you're supposed to clean the drive).

Hope this helps.

[Jennifer Chiarelli]

I had a tape drive in which the clean tape light would come on intermittantly (but not during a backup). HP service replaced the drive and fixed the problem.

[Bill Hassell]

fbackup (and other classic Unix utilities like tar, cpio) have no compression capability. Compression is turned on by the device file options. In HP-UX 10. and 11. the device files are decoded with lssf as in lssf /dev/rmt/0m where the words:

best density available

means that hardware compression will be used. So the device file controls the compression option.

NOTE: 8 Gb in compressed mode is highly optimistic on a typical vg00 backup of the operating system. Many of the executables and libraries are extremely random and have very little compressable data. Like all compression tools (software or hardware), your mileage will vary. You are guarenteed 4 Gb but everything beyond the uncompressed specification is totally dependent on the files you are storing.

[S. Karunanidhi]

Hi !
1.If your drive is capable of compression, you can see "DCLZ" written on the face of the drive. If not, your drive is not capable of compression.

2. Compression futures can be enabled by using the appropriate device files.
Your tape drive will be /dev/rmt/0

Now, these are the options you can include,

l - low density
m - medium density
h - high density
u - ultra density
c - compression enabled
n - no rewind
b - Berkly standrard

You can try using /dev/rmt/0hn and check. Of course, you have to have 8 GB of data in your hard disk to back up so that we can check whether it is successful or not.

Please note that fbackup is not capable of appending data to same tape

Regards,
S.Karunanidhi

[Doug Schroeder]

Wow,

Lots of knowledge out there. OK. The responses have lead me to believe that I should be getting compression if I use the correct device driver. I am currently using
0m. Seems like I should be using some other device. Here's my /dev/rmt/ directory:

HP-UX B.10.20 C 9000/869 475534321 32-user license
# ls -lrt
total 0
crw-rw-rw- 2 bin bin 205 0x010080 Dec 7 1995 0mb
crw-rw-rw- 2 bin bin 205 0x0100c0 Dec 7 1995 c1t0d0BESTnb
crw-rw-rw- 2 bin bin 205 0x010040 Dec 7 1995 c1t0d0BESTn
crw-r--r-- 1 bin bin 205 0xfffffe Dec 7 1995 stape_config
crw-rw-rw- 2 bin bin 205 0x010040 Dec 7 1995 0mn
crw-rw-rw- 2 bin bin 205 0x0100c0 Dec 7 1995 0mnb
crw-rw-rw- 2 bin bin 205 0x010080 Dec 7 1995 c1t0d0BESTb
crw-rw-rw- 2 bin bin 205 0x010000 Jun 28 12:11 c1t0d0BEST
crw-rw-rw- 2 bin bin 205 0x010000 Jun 28 12:11 0m
#

Looks like there is no driver for compression enabled or higher density. My drive does not have "DCLZ" written on it's face. I need to get a different device driver or use a backup utility that has a software compression option?

It was not coincidence that the backups stopped after ~4GB:

-the fbackup stdout mentioned it had reached normal EOT
-this only started happenining as disk space grew. I added all backed up volumes (output of dbf command) and came up just shy of 4Gig.

Thanks.

[Rick Garland]

fbackup is a great tool for doing HP backups and restores, but if you need the files on another platform.... Lets not forget about the compression issue as well.

What is used around here is the standards UNIX utility of dump/restore. The dumps are going to the device /dev/rmt/c0t0d0BEST (example) and this does compression. One nice thing about this methodology, if files are needed on a SUN or Linux or whatever, dump/restore exists are the other flavors.

If you never have to restore files on another platform besides HP, fbackup is good.
BTW, never say never.

[Tom Wittenberg_1 · Accepted solution]

The C1533 drive sould be able to back up ~8gb using compression. Someone in the forum said if you tape drive doesn't say DCLZ on the front panel it doesn't do compression. This is not true. The DCLZ was the first(earliest) indication that your HP tape drives used compression. Now any HP drive with DCLZ,DDS2, or DDS3 use compression. If /dev/rmt/0m points to that drive it should already be set up to the highest(BEST) compression. You can try this to determine if this is the case do a "lssf /dev/rmt/0m" it should come back with a string that contains "at&t best density available". Next run "ls -li /dev/rmt" this gives an inode # in the first column and your /dev/rmt/0m and your /dev/rmt/c1t0d0BEST should have the same inode # proving they are the same file and both using the BEST compression. My main concern with you situation is that you said you have have a amber clean light flashing. The flashing cleaning light is an indication that it is having a problem writing to tape. It can be the tape head is dirty,the tape is bad, or the enviroment the tape drive is in is out of spec. What happens when the tape drive has errors writing to tape is that the tape drive advances the tape and tries the write again. If enough of this happen it can significantly decrease the amount of data that can be put on the tape. Try to clean the tape drive 3 times in a row and try bacing up again. You might try it with a new tape, but you need to realize that a brand new tape,one right out of it's wrapper, is the dirtiest tape you can put in you tape drive so clean the tape drive right after using a new tape. Make sure you are using good HP cleaning tapes for this test. A good cleaing tape should stay in the drive ~45secs anything much shorter than that indicates that the cleaning tape is used up(bad) and needs to be replaced. Usually a bad cleaning tape will kick out in less then 20seconds. If your environment doesn't seem bad and you are still having errors it is probably time to get the drive replaced. Again remember that you will probably never get 8GB on a tape as others have said. So if cleaning it 3 times gets rid of the cleaning light and you still can't get your full backup on one tape it may just be the limitation of the data that you are storing and the inability of the drive to compress that data down.

[Doug Schroeder]

Thanks folks.

Apparently Tom was correct. I replaced the drive with a new 1533a and now I can back up > 4gig of data. Prior to that I had tried several differect cleaning tapes. The backup media I was using all differed in age for each days backup. None of the tapes were new though. Either the backups were skipping a lot of media due to the bad drive or the error condition(s) was causing the data not compress I suppose. Either way I found it hard to believe that a bad/dirty drive would reduce the quantity of data backed up, but would not cause the backups to fail. Lesson learned. THANKS!