- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Backup problems with tapes
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-15-2007 11:52 PM
10-15-2007 11:52 PM
Backup problems with tapes
$ init/med=compac mke500: xyz
$ mount/for/med=comp mke500:
Magtape MKE500:, device type TZ89, is online, allocated, deallocate on
dismount, mounted foreign, record-oriented device, file-oriented device,
error logging is enabled, controller supports compaction (compaction
nabled), device supports fastskip.
Error count 0 Operations completed 434343
Owner process "system" Owner UIC [1,2]
Owner process ID xxxxxxxx Dev Prot S:RWPL,O:RWPL,G:R,W
Reference count 4 Default buffer size 512
Volume label "xyz" Relative volume no. 0
Record size 0 Transaction count 1
Mount status Process Mount count 1
ACP process name ""
Density TK89 Format Normal-11
Volume status: odd parity.
$ backup/image/media=comp/ignore=inter mke500:xyz.bck/save/block=30720
Q.
1. Is there any qualifier or system logical to use with backup command that would keep tabs of the amount of blocks it has processed?
2. Maybe we have a mixure of Tape from difference vendors?
3. Maybe some of the tape are knacked?
Any other ideas?
http://www.imation.com/support/compatibility/midrangecompchart.html#dlt
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-16-2007 12:14 AM
10-16-2007 12:14 AM
Re: Backup problems with tapes
If you 55 GB contain compressed files (zip), you will only get 35 GB on the tape.
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-16-2007 12:14 AM
10-16-2007 12:14 AM
Re: Backup problems with tapes
that a 4000 can't do TK89:
TK85 DLT Tx85: 10625 BPI-Cmpt III - Alpha only
TK86 DLT Tx86: 10626 BPI-Cmpt III - Alpha only
TK87 DLT Tx87: 62500 BPI-Cmpt III - Alpha only
TK88 DLT Tx88: (Quantum 4000)-Cmpt IV - Alpha only
TK89 DLT Tx89: (Quantum 7000)-Cmpt IV - Alpha only
but no matter.
1. None of which I'm aware.
2. Shouldn't matter.
3. Unlikely.
> [...] In theory that should all fit on just
> on tape. [...]
Time for a new theory?
You seem to believe that when the vendor says
something like "35/70GB", you can trust the
larger number. You can't. It assumes a 2:1
compression ratio, which, while typical,
depends greatly on the compressibility of the
data. Random data, or data which have
already been compressed will not get 2:1
(additional) compression from a tape drive.
If SHOW DEVICE /FULL saya "TK89", then I
assume that you don't need it, but I'd tend
to specify a /DENSITY when I mounted the
tape.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-16-2007 12:16 AM
10-16-2007 12:16 AM
Re: Backup problems with tapes
TK89 is 35/70 indeed.
And of course it is possible that your tapes are that bad that they contain lots of bad blocks and thus need more tape per GB.
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-16-2007 12:25 AM
10-16-2007 12:25 AM
Re: Backup problems with tapes
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-16-2007 12:48 AM
10-16-2007 12:48 AM
Re: Backup problems with tapes
alp $ show devi /full dlt
Magtape ALP$MKB400:, device type Quantum DLT4000 CPQ DRV, is online, allocated,
[...]
And its handle says "20/40 GB DLT". A
"QUANTUM DLT7000" says "35/70 GB DLT" on its
handle.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-16-2007 01:17 AM
10-16-2007 01:17 AM
Re: Backup problems with tapes
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-16-2007 01:38 AM
10-16-2007 01:38 AM
Re: Backup problems with tapes
Assuming that "si" was really "so", then I'd
say, "Yes." (Or, "Si.") A possibly reliable
table may be found at:
http://www.discinterchange.com/dec_tape_drives_.html
HELP MOUNT /DENSITY does offer some clues,
too.
But all that other stuff about not being able
to rely on 70GB remains true.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-16-2007 01:40 AM
10-16-2007 01:40 AM
Re: Backup problems with tapes
Of course, if it's really a 4000, then I'd
tend to doubt that you're really getting TK89
density (35/70 GB). Have you looked at the
lights on the front panel?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-16-2007 01:54 AM
10-16-2007 01:54 AM
Re: Backup problems with tapes
Nobody's hinted at the pitfalls of /ignore=interlock a favourite of many, see Hoff's page...
http://www.hoffmanlabs.com/vmsfaq/vmsfaq.txt
REgards
John.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-16-2007 02:45 AM
10-16-2007 02:45 AM
Re: Backup problems with tapes
here is an example of such a progress report:
%BACKUP-I-PROGRESS, progress report generated at 25-SEP-2007 22:37:21.93
Last file scanned: DSA1:[TSV.Veranstaltungen.Kloenschnack.2007.Bilder]MVI_1260.AVI;1
Saveset volume:1, saveset block:17660 (32256 byte blocks)
543.25MB saved, save rate: 1.80MB/sec
We include it in our regular backup every 5 minutes.
regards Kalle
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-16-2007 03:04 AM
10-16-2007 03:04 AM
Re: Backup problems with tapes
Makes me want to upgrade :-)
... but then we use save set manager to tape :-(
Cheers !
John.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-16-2007 10:19 AM
10-16-2007 10:19 AM
Re: Backup problems with tapes
Did you use the /REWIND on the 2nd, 3rd try (if you retried it)?
Even after a DCL-INIT I would still use /REWIND for the first save set.
And unless you are sure check what BACKUP thinks the total size is:
$ BACKUP ... NLA0:a.a/SAVE/LIST
...and check the total size at the end of the listing output.
/Guenther
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-16-2007 05:03 PM
10-16-2007 05:03 PM
Re: Backup problems with tapes
TZ89 = DLT7000 which has native capacity of 35GB.
Compression is very data dependent.
Turn off xor redundancy, it buys you very little on a DLT drive. Use the /group=0 switch of turn it off. The Backup command you showed was using the default redundancy (XOR) group of 10 meaning that for every 10 blocks of data written there will be one additional block written that is the XOR of the previous 10 blocks. This block in general has more entropy (looks more random) than the other blocks and will compress less, so the overhead is often greater in compressed mode than non-compressed mode.
When you are reusing a tape and you want to overwrite the previous data, always use /REWIND and /MEDIA=COMPACTION (if you want compression enabled). This is best even if you have initialized the tape /media=compaction. It may not help, but it never hurts.
The DLT IV tape capacity depends on the type of drive it is used in. The tapes you buy now will say 40/80 GB but that is only achievable on a DLT8000 drive. In a DLT7000 the same tape will hold 35/70, in a DLT4000 20/40.
Also see the previous thread concerning TZ89
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1143795