topic Re: Backup problems with tapes in Operating System - OpenVMS

Backup problems with tapes

VMSdude — Tue, 16 Oct 2007 06:52:17 GMT

Need to backup/image a 70GB disk of which 55GB is in use. Have IMATION IV DLT tapes which I believe are 35/70GB in capactiy in size with a DLT4000 drives. In theory that should all fit on just on tape. In practice the backup want two 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

Re: Backup problems with tapes

Wim Van den Wyngaert — Tue, 16 Oct 2007 07:14:13 GMT

Per default, backup add /group=10, adding an overhead of 10$% for error correction. The good news is that this is useless for tk89 and you can add /group=0 to avoid this overhead.

If you 55 GB contain compressed files (zip), you will only get 35 GB on the tape.

Wim

Re: Backup problems with tapes

Steven Schweda — Tue, 16 Oct 2007 07:14:42 GMT

Around here, HELP MOUNT /DENSITY suggests
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.

Re: Backup problems with tapes

Wim Van den Wyngaert — Tue, 16 Oct 2007 07:16:51 GMT

http://en.wikipedia.org/wiki/Digital_Linear_Tape#Generations

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

Re: Backup problems with tapes

Wim Van den Wyngaert — Tue, 16 Oct 2007 07:25:07 GMT

IMATION IV is 40/80 GB. Thus tk89 in optimistic mode.

Wim

Re: Backup problems with tapes

Steven Schweda — Tue, 16 Oct 2007 07:48:01 GMT

For the record, also around here:

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.

Re: Backup problems with tapes

VMSdude — Tue, 16 Oct 2007 08:17:29 GMT

The mke500 is tz89 si its a DLT7000? and is mounted at the correct denisty: TK89

Re: Backup problems with tapes

Steven Schweda — Tue, 16 Oct 2007 08:38:01 GMT

> The mke500 is tz89 si its a DLT7000?

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.

Re: Backup problems with tapes

Steven Schweda — Tue, 16 Oct 2007 08:40:47 GMT

> The mke500 is tz89 si its a DLT7000?

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?

Re: Backup problems with tapes

John Abbott_2 — Tue, 16 Oct 2007 08:54:36 GMT

1. VMS V8.3 has backup/progress_report (I've not used it - any good anyone ?). If you know your disk i.e. how much GB is in each directory tree [...] then a sh dev/fi of the input device *might* help knowing where's it at.

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.

Re: Backup problems with tapes

Karl Rohwedder — Tue, 16 Oct 2007 09:45:41 GMT

John,

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

Re: Backup problems with tapes

John Abbott_2 — Tue, 16 Oct 2007 10:04:47 GMT

Thanks

Makes me want to upgrade :-)

... but then we use save set manager to tape :-(

Cheers !
John.

Re: Backup problems with tapes

Guenther Froehlin — Tue, 16 Oct 2007 17:19:19 GMT

If the tape drive has some front panel indicators...does it show the compressed format when BACKUP runs?

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

Re: Backup problems with tapes

Jon Pinkley — Wed, 17 Oct 2007 00:03:16 GMT

Summary of previous posts:

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