tk89

[Dean McGorrill]

I've never had any real experience with tapes.
we have backup scripts going and someone to
blindly shovel in tapes.

Now I want to make full images to tape of all
my disks. I have a DLT IV new out of the box.
do I need format it, or do anything before
using it? tx Dean

[Andy Bustamante]

You can INIT the tape with a meaningful label or allow BACKUP to create it's own label. If you opt to use init, you'll need to specify /label=xxx in the image backup or use /ignore=(label). If you put tapes into rotation, review the EXPIR options to safeguard your backups.



Andy

[Dean McGorrill]

ok, so the tape comes ready to use out
of the box. I see from help init has a density switch, that doens't need to
be used?

Valid density values are as follows:

Keyword Meaning

DEFAULT Default density
800 NRZI 800 bits per inch (BPI)
1600 PE 1600 BPI
6250 GRC 6250 BPI
3480 IBM 3480 HPC 39872 BPI
3490E IBM 3480 compressed
833 DLT TK50: 833 BPI
TK50 DLT TK50: 833 BPI
TK70 DLT TK70: 1250 BPI
6250 RV80 6250 BPI EQUIVALENT
NOTE: Only the keywords above are understood by
TMSCP/TUDRIVER code prior to OpenVMS Version 7.2.
TK85 DLT Tx85: 10625 BPI - Cmpt III
TK86 DLT Tx86: 10626 BPI - Cmpt III
TK87 DLT Tx87: 62500 BPI - Cmpt III
TK88 DLT Tx88: (Quantum 4000) - Cmpt IV
TK89 DLT Tx89: (Quantum 7000) - Cmpt IV
QIC All QIC drives are drive-settable only
8200 Exa-Byte 8200
8500 Exa-Byte 8500
DDS1 Digital Data Storage 1 - 2G
DDS2 Digital Data Storage 2 - 4G
DDS3 Digital Data Storage 3 - 8-10G
DDS4 Digital Data Storage 4
AIT1 Sony Advanced Intelligent Tapes

[Hoff]

Nope. Toss it in the drive.

But if you want to know the arcana....

BACKUP /IMAGE /REWIND /VERIFY ... etc ...

I'd probably add /MEDIA=COMPACTION and /NOALIAS and /IGNORE=LABEL and /NOASSIST and /BLOCK=32255 ...

and off you go...

If you want to get fancier, you can add specifications of tape labels and such, so that any continuation volumes get the labels you specify.

The usual caveats around the hazards of /IGNORE=INTERLOCK apply; around the silent data corruptions in the output permissible with this qualifier.

If you trust the drive and the media, /NOCRC and /GROUP=0.

If you do manually issue the MOUNT or the INITIALIZE for the DLT tape cartridge, do remember to use /MEDIA=COMPACTION on each of those commands.

Here is some process quota information for obtaining best BACKUP speed: http://64.223.189.234/node/49

Stephen Hoffman
HoffmanLabs LLC

[Hoff]

>>>I see from help init has a density switch, that doens't need to be used?<<<

/MEDIA=COMPACTION is what I'd use. The /DENSITY stuff defaults to the appropriate value, and typically only need be specified if you want to record at a lower density.

[Dean McGorrill]

great,
so for curiosity. if you specify a
density, does the init write the whole tape?
in other words is there a 'format' or is
a tape just totaly blank magnetics?

[Jan van den Ende]

Hoff wrote

>>>
If you trust the drive and the media, /NOCRC and /GROUP=0.
<<<

Well, if it is a SCSI device (and which is not, nowadays?) you have no chaice BUT to trust!

All the nice redundencies & recovery abilities built into BACKUP do just NOT have a chance to prove themselves if the drive refuses to continue to pass on data after a (ususally: parity) error.
(remeber DSA drives; BACKUP encountered xxx recoverable errors during read/write ? )
... and in itself that is explainable, because I do not know of anything except VMS BACKUP that WOULD be able to do anything useful.
Still, a pity that VMS holds so low a profile that tape manufacturers do not deem it relevant to take its abilities into consideration... :-(

fwiw

Proost.

Have one on me.

jpe

[Dean McGorrill]

jpe,
really the tape drives stop after
an error. so I'll use /nocrc. do you know
if theres any format on the tape, or just
blank magnetics?

[Hoff]

True, the standard device firmware tends to punt on errors. Data recovery service device firmware doesn't.

[Wim Van den Wyngaert]

If you init a tape that has been used before, it will be init with the same density as it had on the original init,
not the best value of your current drive.

I wonder if all drives have the best density as default ?

To be sure, we specify our density on each init and we init the tape before each backup.

Wim

[Wim Van den Wyngaert]

Fot those who find all that tape stuff confusing (like me) read this :

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

Wim

[Ian Miller.]

Hoff,
Why /NOALIAS ? The current help text suggests the default is the best idea.

/IGNORE=LABEL - not good when people may load the wrong tape

/NOASSIST - depends on operational procedures

/BLOCK=32255 - why not 32256 ?

[Andreas Vollmer]

Hello,

In general all what is needed is already been said.
Here are some more hints.
All media which were previously used in an TZ90 (TK90) with 40/80 GB can NOT be accessed by a TZ89 (35/70 GB) or older!
Because TZ89 does not now about higher DLT tape densities when it was build. Vise versa is no problem.
On a TZ90 you can initialize already used media for older DLT devices by appling the correct density and voi la...
Such as:
INIT /DENSITY=TK88 MKxnnn: test

Please be aware the tape label does NOT exceed 6 characters.
I do recommend to use a blocksize of 65500. This will enable you to use the full media capacity! For sure smaller values will work but you will not be able to use the media capacity due to a higher amount of inter record gaps.
Concering the /NOCRC & GROUP=0 => Hoff is right, the DLT's using there own & reliable error correction mechanism. The DLT do ALWAYS automatically a read after write and can repair single bit errors on the fly.
The OpenVMS Storage engineering confirmed the above mentioned statement during DECus in 1999 in Boston. For performance reason they even encouraged to set the values to /NOCRC & GROUP=0.

Further the compression mechanism, VMS is calling it /MEDIA=COMPACTION improves the performance and enables you to get a better utilisation of the media. For sure the data type is the constraint of the compression ratio (success) such as ZIP'ed files etc.
I mean with this statemnent uncompressed files = normal files can be compressed during the backup to the tape.

Refer to this link for further hints...
http://h71000.www7.hp.com/wizard/wiz_7762.html?jumpid=reg_R1002_USEN

I hope my input was helpful.
Andreas

[Jan van den Ende]

Re Andreas:

>>>
I do recommend to use a blocksize of 65500
<<<

But be aware, that you will then NOT be able to COPY the savesetfile to disk!

Re Hoof, Ian
>>>
/BLOCK=32255 - why not 32256
<<<
Indeed, 32256 is the right number.
It is the highest multiple of 512 that fits in 15 bits.
But Hein can explain that MUCH better than I can!

fwiw

Proost,

Have one on me.

jpe

[The Brit]

Dean,
Regarding your question about formatting, when you "init" the tape, whether it is new or reused, no data is removed (unless you "init/erase", which I don't recommend unless you are happy to wait an hour or two).
All that happens, in this respect, is that the EOD (End-of-Data) marker is written at the beginning of the tape, effectively masking the existance of any previous data on the tape.
If you are using a tape which has been used before, and you DO NOT "init", then the
tape drive will fast-forward to the EOD marker before starting to write, thus preserving the existing data.

Dave

[Ian Miller.]

Personally I agree with /GROUP=0 as normally available scsi tape drives do not allow the redundancy information to be used.

However I think /CRC is still worth using as it is an end-to-end check on the data. The location in the backup header for the CRC is present even if /NOCRC is specified. The overhead is the CPU time required to calculate the CRC, which is a small overhead on alpha and itanium systems.

[Dean McGorrill]

well I think my question is answered, if
you do an init/erase then tape is erased. A init and changing density, it doesn't erase implies that there is no format. I used to boot a home made Rt-11 system
off a tu58 tape which was formatted as
I remember.

if I can just toss the tape
into the drive, it must have been inited
with its correct density at the factory
I will assume. I searched the dcl scripts
around here, and there is no density switch
used in them either. tx for the info Dean

[Cass Witkowski]

Actually the overhead of /CRC can be rather high especially when trying to drive a LTO-2 or LTO-3 tape drive. It can swamp a DS10.

I think OpenVMS engineering looking at ways to reduce the CPU load of /CRC.

I would really like the storage guys getting with OpenVMS engineering to come up with an analysis of what the /CRC really buys you these days with all the newer tape technology.

[Hoff]

>>> Why /NOALIAS ? The current help text suggests the default is the best idea. <<<

At its simplest, because I don't want alias entries replicated in the saveset. I know how the system disk is structured, and I know how to restore individual files, and I know that a BACKUP /IMAGE restoration also knows how to restore the alias entries all by itself. (Assuming current ECOs.)

/NOALIAS makes for significantly smaller BACKUP savesets for system disks. If you use /SELECT to selectively restore individual files from within alias'd structures, and you are not using a full-disk BACKUP /IMAGE for the restore, then you *do* need to know what the primary alias entry is. But the savings in space and time are substantial, and worth it.

(Spent quite some time working with various of the BACKUP maintainers over the years, and the whole /[NO]ALIAS scheme was one of the more interesting episodes.)

>>> /IGNORE=LABEL - not good when people may load the wrong tape <<<

If I am writing a BACKUP procedure, I will typically use the tape expiration mechanism to prevent immediate re-use (which is the most common error), and might potentially set up a list of labels. Otherwise and when working interactively, I almost always use /IGNORE=LABEL. I know what tapes I am loading, and I'd rather not have the processing derailed due to the labels.

Now as for something like creating a procedure to provide a local and slimmed-down SLS or ABS oro ther such, then yes, labels and mayhap barcodes and such. (My interpretation of the O.P. here was that we are working with an interactive one-off all-disk BACKUP.)

>>> /NOASSIST - depends on operational procedures <<<

Correct.

>>> /BLOCK=32255 - why not 32256 ? <<<

Typo.

[Dean McGorrill]

anyone know how many blocks a dlt iv on a tz89 hold?

[Ian Miller.]

About that many :-) It depends on how the data compresses.

Native capacity is stated as 20Gb

[Bart Zorn_1]

Ian,

A small correction: TZ89 with DLT IV tapes has a native capacity of 35 GB.

TZ88 with DLT IV had 20 GB!

Regards,

Bart Zorn

[Dean McGorrill]

35gb, soo,, about 68 million blocks if my
calculaters right..

[Andreas Vollmer · Accepted solution]

Dean,
Theoretically you are right - but...
The TK89 offers data compression and it is therefore capable of 70GB but as I wrote previously it depends at the data type.
The compression of 70GB is calculated and tested at a ratio of 2:1.
Some files such as DB files can be "easily" compressed and others not or not the mentioned ratio of 2:1. That is the reason the 70GB compressed are NOT guarantied but the 35GB will fit in any case.

By the way, just for information, during the dark ages of Bob Palmer the DLT technology, original invented and developed by DEC was sold to Quantum. Quantum uses a slightly different naming scheme as DEC and Compaq.
A TK89 is called DLT7000 and a DLT90 is called DLT8000 etc.
Here are some more interesting links and information about the DLT's, SDLT's etc.
DLT7000 / TK89
http://www.craystone.com/quantum/quantum-dlt7000-specifications.html
Quantum DLT Info...
http://www.craystone.com/quantum/quantum-index.html

I hope this information was helpful
Regards
Andreas

[Dean McGorrill]

>>By the way, just for information, during the dark ages of Bob Palmer the DLT

10 points you get for that one Andreas!!
yes the Bob Palmer dark age as we watched
him dismantle DEC.. Anyway, thanks for the
additional info! Dean