Tape label on multi tape OpenVMS backup

[Wim Van den Wyngaert]

Or split your backups so you have parts that fit on 1 tape (we do).

BTW : how do keep track which tapes has which save set if you afterwards don't know which tape you used ?

Wim

[Jan van den Ende]

Russ,

I think I only now understand your question, but
What problem are you trying to solve?

Are your external (stickered?) tapelabels and your internal (magnetisized) labels the same, and you want to maintain that?

Simple thought experiment:
SUPPOSE an unintended (as in: operator mix up) tape is in the stacker. The label it carries is to be maintained.
Some time later, you need a restore.
HOW will you ever find the correct tape???
_IF_ you swapped the tapes and overwrote the label, you WILL have to load all potential tapes to find the one with your data by checking the label. A time-consuming nuisance, but it can be done rather easily.
But if that label has NO relation to the data????
Especially if most of the data is the same most of the time (as in BACKUPs), that looks like a needle in a haystack.
(remember that you can easily MOUNT a tape and get its label for the first tape, but NOT for continuation tapes. But looking through the backup header for the BACKUP command, and the time info. And precisely THAT is what is in your "haystack").

fwiw

Proost.

Have one on me.

jpe

[Jan van den Ende]

Russ,

if you are still on your original question, have you looked at /IGNORE=LABEL_PROCESSING

I never used it, but it looks like it does what you want. (I did NOT test this!!)

HTH

Proost.

Have one on me.

jpe

[Jon Pinkley]

As Hoff and then RBrown said, the following is a valid backup command:

$ backup /image disk: tape:/exact_order

Specifically note that no /label was specified.

See http://h71000.www7.hp.com/doc/83final/6048/6048pro_022.html#startsubcommand_122

I tried this using LDDRIVER 9.0 with Logical Magtape support, but I was not able to get tapelable processing to work on the second volume, even if all labels were specified. So, I am not sure what the problem is. This using Alpha VMS 7.3-2, which is different than either version Russ is using. The second tape was mounted, but then generated a %BACKUP-F-LABELERR error.

2$ mou/for/nounl lma1
%MOUNT-I-MOUNTED, LM0001 mounted on _SIGMA$LMA1:
2$ backup sys$system:bliss*.exe; lma1:blisster.bck/save/exact_order/group=10/crc/log/rewind/labe=(lm0001,lm0002,lm0003,lm0004)
%BACKUP-W-NOFILES, no files selected from DSA1407:[SYS0.][SYSEXE]BLISS*.EXE;
%BACKUP-S-COPIED, copied DSA1407:[SYS0.SYSCOMMON.][SYSEXE]BLISS32EN.EXE;2
%BACKUP-S-COPIED, copied DSA1407:[SYS0.SYSCOMMON.][SYSEXE]BLISS64EN.EXE;2
%BACKUP-I-RESUME, resuming operation on volume 2
%MOUNT-I-OPRQST, medium is offline
%MOUNT-I-OPRQST, Please mount volume LM0002 in device _SIGMA$LMA1:
BACKUP requests: Saveset BLISSTER.BCK, Volume number 02, write ENABLED
%MOUNT-I-MOUNTED, LM0002 mounted on _SIGMA$LMA1:
%MOUNT-I-RQSTDON, operator request canceled; mount completed successfully
%BACKUP-F-LABELERR, error in tape label processing on LMA1:[]BLISSTER.BCK;
-SYSTEM-F-DRVERR, fatal drive error
2$

And without /label

2$ mou/for/nounl lma1
%MOUNT-I-MOUNTED, LM0001 mounted on _SIGMA$LMA1:
2$ _ back
2$ backup sys$system:bliss*.exe; lma1:blisster.bck/save/exact_order/group=10/crc/log/rewind
%BACKUP-W-NOFILES, no files selected from DSA1407:[SYS0.][SYSEXE]BLISS*.EXE;
%BACKUP-S-COPIED, copied DSA1407:[SYS0.SYSCOMMON.][SYSEXE]BLISS32EN.EXE;2
%BACKUP-S-COPIED, copied DSA1407:[SYS0.SYSCOMMON.][SYSEXE]BLISS64EN.EXE;2
%BACKUP-I-RESUME, resuming operation on volume 2
%MOUNT-I-OPRQST, medium is offline
%MOUNT-I-OPRQST, Please mount device _SIGMA$LMA1:
BACKUP requests: Saveset BLISSTER.BCK, Volume number 02, write ENABLED
%MOUNT-I-MOUNTED, LM0002 mounted on _SIGMA$LMA1:
%MOUNT-I-RQSTDON, operator request canceled; mount completed successfully
%BACKUP-F-LABELERR, error in tape label processing on LMA1:[]BLISSTER.BCK;
-SYSTEM-F-DRVERR, fatal drive error
2$ sho dev lm

Device Device Error Volume Free Trans Mnt
Name Status Count Label Blocks Count Cnt
SIGMA$LMA0: Online 0
SIGMA$LMA1: Mounted alloc 0 LM0002 0 1 1
foreign
2$

The /exact_order qualifier is overloaded, and does several things. One thing is always does is prevent the reuse of a tape label within the same backup operation. This prevents accidents like an operator reloading the same tape in response to a request to mount a continuation volume.

Russ, have you tried the above? I.e. without specifing any label? It may work, and it may not, but I don't have either 6.2 or 7.1 available to try.

To Wim's question about how you can determine what tape contains what files, backup journal files work fine. We generally use a journal file for each disk, and create a new one when we do a backup .. /record operation. Then it is easy to find the latest version of a file that existed on a specific disk, whether it was on the initial backup disk:/image/record or on a "differential" backup made with backup disk:[000000...]/mod/sin=backup/norecord

I think what Russ is asking is that any of the "scratch" tapes that an operator selected form a scratch pool should be accepted, but that backup should not change the label of the tape. That appears to be exactly what /exact_order does if /label is not specified.

And journal files provide for keeping track of what tapes were actually used.

Like Wim, we actively avoid spanning tapes (i.e. we never fill tapes so they don't attempt to go to continuation volumes.) We don't currently have tape libraries, just multiple drives that are used simultaneoulsy for different disks, and we don't have 24 hour operator coverage, so we don't want backups to wait for an operator to change tapes.

If /ignore_tape label processing is used (and it can't be used with /exact_order), then tape labels will be overwritten.

Jon

[marsh_1]

Russ,

i think your original request was to know the labels of the tapes in your stacker in advance. steven schweda has already answered this in an earlier reply. just mount the tapes one at a time assign unique logicals to each f$getdvi request and use the /label and /exact backup qaulifiers. how you deal with tape errors et al
given your restrictions is something you need to decide.

[Russ Carraro]

Jon,

I'll try it with just "/exact" and let you know.

Historical information: some sites have been running these backups for years. The external (sticky) labels are TAPE01 ... TAPEnn. They use the tapes in sequence. Each night, whatever tape they've mounted, gets initialed to the same default label, so external and internal labels do not match. User maintains a manual log of what external label was used on what day. The backup process also writes what SHOULD be the external label to an index file. I keep this file as a backup (just in case)listing, even though it may not be 100% accurate.

The customer wants to use this backup process at other sites so my thought was that if I can capture the internal label, and not destroy that label, of those tapes and write them to the index file then that could replace the manual log. I can capture the internal label of the mounted tape but the problem is how do I capture and not overwrite the internal label subsequent tapes when the backup goes to multiple reels. If I can capture those labels then the customer will not have to renumber a bunch of tapes, too.

[Russ Carraro]

Mark,

I could mount/dismount each tape and build a "/label=" parameter but, without getting the user involved, how do I get the original tape remounted? Also, if the last tape is used and backup still needs a second reel, when the user does load new tapes how do I capture that label?

[Jon Pinkley]

Russ,

I pasted the wrong version of my last message. The last part should be:

------------
If /ignore=label_processing is used (and it can't be used with /exact_order), then tape labels will be overwritten.
------------

Russ, if I understand, the customer has (less than 100) tapes externally labeled TAPE01, TAPE02, ... , TAPEnn.

They then do a backup (with some unspecified backup command that we are supposed to guess), and these backups commands use some "default" label (again not specified, so we have to guess). If by "same" you mean FIXED, (for example /label=backup) then won't multiple physical tapes have identical internal tape labels in the Tape header records?

I have to ask. Why do you want to automate a broken procedure? Why not fix it instead?

Before reusing the tapes, reinitialize the tape with the external label, so something like backup journal files can tell you what tape to grab. Once you have gone through the cycle once, then your internal and external labels will be consistent, (although for tapes with long retention, that will not be the case until they are recycled).

If you are lucky, the "default" label that is being used does not start with "TAPE". If it does not, then you will be able to tell if the tape is using the old or new internal label convention. Otherwise, I have no idea how you would be able to determine what physical tape to grab if the journal file said to get TAPE02. This is especially true if you are not currently using /exact_order. I suppose you could use the date and the label to determine the physical label, but that is not nearly as nice as if each tape has a unique label that is consistent internally and externally. I would also recommend that each site use a different "base" name, so if tapes from multiple sites are stored in a common offsite facility, they are not inadvertently miss identified. In other words, if you request tape TAPE02 and every other site also has a tape with the external label TAPE02, it is more likely to cause confusion than if they were labeled PHX002 and ATL002.

Also, what safeguards do you use to prevent an operator from loading non-scratch, i.e. tapes that have not reached their "expiration date"? Do your backups use /tape_expiration='date' when you specify /rewind?

We do use /tape_expiration and it has prevented accidental overwriting of tapes several times. It isn't fail proof, i.e. it is relatively easy to reinitialize tapes if you try harder, but backup will refuse to overwrite a tape (at least if /label_processing is in effect).

So, although the documentation suggests that backup disk: tape:/exact_order will do what you asked, it will not handle the case where you have a tape that has not yet expired. And it doesn't address a write locked tape being loaded into the stacker either.

I suggest the following:

When the operators load the stacker with the tapes to be used for the next backup, have them submit a "validation" job to mount/foreign each tape, verify and possibly save the labels found with f$getdvi(dev,"VOLNAM"), validate that the tape is not write locked with f$getdvi(dev,"SWL"), read the tape header record and verify that the tape is expired, and then go to the next tape. This can then generate that backup command with the specific tape labels. Evidently, the drive/stacker you have is the "load next tape when tape unloaded, unload stacker after last tape" type. If so, you will need the operator to reload the stacker after the validation. However, in my opinion, it is better to find a potential problem while someone is available than to discover a problem when everyone is at home.

If you want some example DCL code to extract the expiration date for the tape header record, let me know and I will attach to a comment.

RE:"Also, if the last tape is used and backup still needs a second reel, when the user does load new tapes how do I capture that label?"

The only way I am aware of is to look at a log file or backup journal file. Since BACKUP is controlling the mounting/dismounting of continuation volumes, and I am not aware of any callouts available, I don't know if it is possible to get this information directly, although I haven't played with callable backup.

Jon

[Hoff]

While the customer is always right, I'd have a discussion with the customer prior to replicating this particular scheme -- even if they decide to continue with the current scheme, it's best if they know the trade-offs and the risks. (You probably don't want your employer -- still working for the same bunch of folks, BTW? -- left holding the bag for a botched backup.)

[marsh_1]

Russ,

you could know which tape is being put in next after the stacker has been used up by telling the customer which tapes to load in advance i.e you maintain a tape list and automatically release tapes from it , these could be communicated to the customer as the tapes to load and the order in which to load them. the backup procedures would need to be self adjusting using the labels that remained after each had completed.
so this is starting to get more complicated now and there so many potential holes as pointed out by the other contributors that i would tend to agree with hoff that this is worth a conversation with the customer.
you might start looking at a larger library and or a proper backup software package (not all of them cost a fortune)