Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Checking amount of tape used..ufsdump/ufsrestore

Status
Not open for further replies.

dandan123

Technical User
Sep 9, 2005
505
US
I'm trying to help one of our remote locations with backuping up data on a DLT8000 using ufsdump.

The dumps are done in the night and due to their data growing it no longer fits on one tape. ufsdump prompts for a second tape and since theirs no one to change the tape it aborts.

I understand that the DLT8000 has a native capacity of 40GB and with compression it goes up to 80GB.

I've turned on compression using the /dev/rmt/0cn device. How do I check how much of the tape is being used with and without compression ?

I would like to dump a file onto a tape with compression and again without compression to compare.
 
You should be able to get an idea of how much data is being written to the tape using a log file for the ufsdump. For example, our log gives the following information for each file system backued up:

The total size is 26291232784 bytes.
The total size is 19139878912 bytes.
The total size is 273741478 bytes.
The total size is 3787230827 bytes.
The total size is 26295205904 bytes.
The total size is 19143852032 bytes.
The total size is 276649028 bytes.
The total size is 17578835991 bytes.
The total size is 6665121148 bytes.
The total size is 1673132333 bytes.

By adding up the totals, you thus get an idea of the amount of data written to tape.



Alan Bennett said:
I don't mind people who aren't what they seem. I just wish they'd make their mind up.
 
That's telling how much uncompressed data has been written to the tape; I believe he is trying to determine how much effect the hardware compression is having and how much free space is left on the tape. I believe this would be hardware dependent, if mt cannot report it you may need some special software from the hardware vendor to query the drive.

Annihilannic.
 
Annihilannic, that's exactly what I'm trying to do.

man mt hasn't provided much information but I need to revisit it again when I get some time.
 
afaik there is no information about how many meters or feet of tape is used. Any backup utility, such as ufsdump, Legato, NatBackup, ..., works the same way: send a stream to the tape device. Depending in HW switches or the used device, the drive will write in native mode or compressed data. The drive will write to the tape until it finds the end of tape mark on the volume. The drive will indicate a "tape full" to the host. Depending on the software this will initiate a tape rewind and tape change or prompt for next action.

To cut a long story short, dandan, run your ufsdump as many times on the same tape. At which dump and percentage does it prompt for the next tape? This might be an indication abou how much does your data compress (7bit ASCII vs. mp3)...

Best Regards, Franz
--
UNIX System Manager from Munich, Germany
 
I turned on compression and now the backups are fitting on the tape.

It's a DLT8000 so uncompressed you get a capacity of 40GB while compressed you get 80GB.

I was trying to check if compression was really working before I set up unattended backups.

Anyway, after enabling compression the backups are fitting onto one tape and are no longer failing.

Thanks for all the responses.
 
80GB is only an estimate. If you were backing up already compressed data, such as MP3s as daFranze suggested, or lots of gzipped files, you wouldn't get anywhere near that.

Glad to hear it's working for you now anyway.

Annihilannic.
 
The files being backed up are not compressed files, mainly oracle files/database.
 
Code:
It's a DLT8000 so uncompressed you get a capacity of 40GB while compressed you get 80GB.

afa remember the tape label says "asuming a 2:1 compression"; with 7bit ASCII you could asume a 10:1 compression, with lots of mp3 you could asume a 0,x: 1 "compression"

Best Regards, Franz
--
UNIX System Manager from Munich, Germany
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top