Problems with restore from tape

[Kirsten Knüttel]

Hello,

I've got a problem with a restore and I really don't find the solution. Perhaps, somebody of you has got a hint....

I've got OpenVMS 7.3-1 on an Alpha Server

For tests, I've made of all disks a backup on tape (TZ88) with the following command:

backup/image $1$dua240: $42$mka300:dua240.bck /label=240bck

Now I want to restore the disk on an empty volume (with a TZ89), but the command

backup/image $41$mka400:dua240.bck $1$dga240:

doesn't work. The error message is always file not found. When I mount the tape /over=id I can see the file and when I mount the tape /foreign I can do a backup/list on the file. Everything is no problem.
The onliest restore command, that worked was:
backup/image $41$mka400: $1$dga240:
Even with *.* it doesn't work.

With the restore of the files, it was "no problem" because I had only one file on a tape. Now I have to restore the databases (with 2 or more RBF-files on a tape) and the same error occurs.

I hope, somebody has got an idea, where I can search for the error.

Regards,

Kirsten

[Robert Gezelter]

Kirsten,

I do not have a tape drive handy to reproduce precisely what you are doing, but I note that the command line in the posting did not include the /SAVE_SET or /REWIND qualifiers for the tape.

As far as I know, you can only restore one saveset at a time.

- Bob Gezelter, http://www.rlgsc.com

[Jon Pinkley · Accepted solution]

Kirsten,

Your backup to tape didn't include /rewind, so it is possible that you have multiple savesets on the tape with the same name, specifically dua240.bck, since the "default" action of backup (post v.5.5?) has been /norewind, and this appends a saveset to the end of the tape.

I would suggest creating a complete backup listing of the tape.

$ mou/for $41$mka400:
$ backup/list=240bck.lis $41$mka400:*.*
$ search/nowindow 240bck.lis "save set:"

If you have multiple savesets on the tape that have the same name, you will need to either position the tape to the correct location using set mag/skip=fil=xxx (note that xxx is not the save set number, but you can derive the correct number of filemarks to skip given the save set number. See replay dated Jul 14, 2007 02:21:58 GMT in thread http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1144759

Alternatively, you can list all preceding savesets with backup to position the tape, then issue your backup command to restore.

It isn't clear to me whether the tape you have was created with backup or with the RDB backup utility. It have been over 12 years since I used RDB, but if I remember correctly, it was possible to write RBF files directly to tape, and these have to be restored with the RDB backup utility.

Doing a backup listing of the tape will tell you whether what you have on tape is a VMS backup saveset or not. If it isn't a VMS backup saveset, then VMS BACKUP won't help in the restore.

If on the other hand, the RBF files were written to a disk, and then those files backed up to tape using VMS backup, you are on the correct track, but you may be selecting the incorrect saveset on the tape.

Good luck,

Jon

[Jan van den Ende]

Re Robert,

Kirsten, essentially Robert is correct, but (lucky to you!) those qualifiers ARE the default.
So, unless you did define symbol BACKUP that changes those settings, you ARE OK in that respect.

Proost.

Have one on me.

jpe

[Jon Pinkley]

See

$ help backup/rewind
BACKUP

/REWIND

/REWIND
/NOREWIND (default)


This has been the default for about the last 15 years. Originally it was /REWIND, but that was a dangerous enough default that it was changed even though it had the possibility of breaking existing command procedures. I am not sure when it changed, but it was definitely before V6.0, I think it was in the 4.4 or 5.5 release.

Note that when restoring, if you mount a tape, and don't do anything to cause the position to be changed, either /rewind or /norewind will read the first saveset on the tape.

The help has more details, which you can read directly.

Jon

[Kirsten Knüttel]

@Robert:

I've tried it with a /REWIND before and within the command. The /SAVE_SET command is not used with a tape and with the /IMAGE.
My problem is, what can I do when I've got more than one saveset on the tape. At the moment it was easy, because I only had one file on the tape. When I had to specify a saveset I couldn't do the restore

@ Jon:

I have the problems with the normal backup operation and with the RMU/RESTORE. My description was for an image backup of a normal disk with normal files.
The second phase is now for me, to restore databases from the tape to the disk (with the RMU command) and here I had the same error.

[Jon Pinkley]

RE: "My problem is, what can I do when I've got more than one saveset on the tape. At the moment it was easy, because I only had one file on the tape. When I had to specify a saveset I couldn't do the restore"

The short answer is: Make sure you use unique saveset names, and remember there is a 17-character limit (including the dot) for file names on ANSI tapes.

So I would suggest something like DUA240.F071105 as a saveset name for a full image backup created on Nov 5, 2007.

The previous thread I referenced also reported that save sets couldn't be found.

I have not had problems specifying backup savesets with any version of VMS backup in 6.2, 7.1-2, 7.2-2 or 7.3-2. I always explicitly mount/foreign the tapes, i.e. I don't allow backup to do it implicitly.

I can't be of any help with RMU backup, since I don't have it available.

Good luck,

Jon

[EdgarZamora_1]

Jon gave you the answer previously. If you have multiple savesets on the tape use the SET MAGT/SKIP=FILES:n to position the tape to the saveset you want to restore.

For example, if I wanted to restore the 3rd saveset on the tape:

$ set magt/rew $41$mka400:
$ set magt/skip=file:2
$ backup/image $41$mka400: $1$dga240:

highly unlikely, but if you don't know what savesets are on the tape, use backup/list= as Jon mentioned above to get a listing of the savesets.

[Jon Pinkley]

@Edgar

My experience with set magtape/skip=files=n is that n is not the saveset number.

If the tape has the following savesets:

1.BCK
2.BCK ! set magtape/skip=file=2 (but this may not use fast skip)
3.BCK ! set magtape/skip=file=5
4.BCK ! set magtape/skip=file=8
5.BCK ! set magtape/skip=file=11

i.e. if ssn is save set number (starting with 1) then files to skip, n = ssn*3-4

See http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1144759 reply dated Jul 14, 2007 02:21:58 GMT

[Jon Pinkley]

More examples of using $ set magtape/skip=file in following thread: http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1143795 reply dated Jul 21, 2007 05:26:07 GMT. It has a log of usage showing how to position a DLT tape.

Jon

[Guenther Froehlin]

BACKUP/LIST uses about the same code paths as a BACKUP restore to open and read a save set file.

BACKUP leaves a tape postioned when it has completed a task.

I can only imagine that a save was done following right away by a restore operation without a /REWIND specified for the restore. Since BACKUP only skips forward to search for a file it could not find the save set.

/Guenther

[EdgarZamora_1]

You learn something new everyday. Thanks Jon. I could've sworn I did this in the distant past. Maybe I never skipped more than 1 "file".

Nevertheless, Kirsten the SET MAGT/SKIP=FILE:n would be the command to use to position to the right saveset. Use Jon's formula.

[David Jones_21]

I seem to recall some issues with case sensitivity to backup saveset names on tape when we first deployed EFS on 7.3. Try changing process parse style to traditional if it is currently extended.

[Guenther Froehlin]

David,

there was a BACKUP fix for case sensitivity earlier this year. I wonder why the BACKUP/LIST then worked.

/Guenther

[Jon Pinkley]

We aren't using EFS, (still using ODS2 for all production data), so that is something I have never tested. So if you are using EFS, David's suggestion may solve the problem of not finding the saveset on tape, at least until the patch is applied (assuming the patch was back ported to 7.3-1).

It wasn't clear if a saveset name was specified on the backup/list command. If it was, then I can't explain why the list would have worked.

Kirsten, what version of VMS Backup are you using?

$ analyze/image/select=(ident,link) sys$system:backup.exe;

And what does

$ show process/parse_style

display as parse style: ?

I don't see any way to retrieve the state of parse style using the f$environment lexical function, at least in 7.3-2. Has that been added to newer versions? If seems that could be a useful item to have a command procedure be able to save before changing the parse style.

[Kirsten Knüttel]

@ Jon:

The backup /list command I use with the save-set name. So I don't understand why the restore command can't find the save-set when I give him the name, too. And, yes, I've done a rewind every time before I use a backup-command.
In the documentation I've found the following things:

To restore the save set, enter the BACKUP command with the /IMAGE qualifier, using the following syntax:
BACKUP/IMAGE device:save-set-specifier [/SAVE_SET] output-device

BACKUP/IMAGE save-set-specifier ddcu:
$ BACKUP/IMAGE MTA0:17AUG.BCK DRA3:

The examples don't work. The command, that worked was:

$BACKUP/IMAGE MTA0: DRA3:

Here the results for your answer:

BDE04> analyze/image/select=(ident,link) sys$system:backup.exe;
SYS$COMMON:[SYSEXE]BACKUP.EXE;1
"AXP731R006"
16-SEP-2004 15:26:36.32


BDE04> show process/parse_style

6-NOV-2007 08:32:53.02 User: LIEBIG Process ID: 20665077
Node: BDE04 Process name: "LIEBIG"

Soft CPU Affinity: off

Parse Style: Traditional

[Jon Pinkley]

Kirsten,

It appears you have the latest patch to backup for VMS 7.3-1

ftp://ftp.itrc.hp.com/openvms_patches/alpha/V7.3-1/VMS731_BACKUP-V0300.txt

Can you please supply an example of the commands (including any explicit mount commands if they were used) you used to create multiple savesets on the tape, and the commands you used to attempt the restore, with the error message that backup generated?

For example, I would have used something like the following:

$ init mkd600: demo/media=compaction
$ mount/for mkd600:/nounload
%MOUNT-I-MOUNTED, DEMO mounted on _SIGMA$MKD600:
$ backup/rewind/image/block=32256 disk1: mkd600:disk1.f071105 /group=0/media=compaction/label=demo/exact_order
$ backup/norewind/image/block=32256 disk2: mkd600:disk2.f071105 /group=0/media=compaction/ label=demo /exact_order
$ backup/norewind/image/block=32256 disk3: mkd600:disk3.f071105 /group=0/media=compaction/ label=demo /exact_order
$ dism/nounl mkd600:
$ mount/for mkd600:/nounload
MOUNT-I-MOUNTED, DEMO mounted on _SIGMA$MKD600:
$ mount/for disknew:
$ backup/image mkd600:disk3.f071105 disknew:

And I would expect it to find the third saveset, and make a logical duplicate of disk3: to disknew:

Or to save some time if fast skip was enabled on mkd600: I could insert the following after the last mount:

$ set magtape/skip=file:5 mkd600:

which would position to right before the 3rd saveset, and the backup command would find the next saveset to be the one it was looking for.

Jon

[EdgarZamora_1]

Actually what would be very helpful here is if Kirsten can attach the backup listing of the tape in question. (Just the initial parts would be good, you can cut off the file listings).

Are you using the same system/account (to try and restore the tape) as the one used for creating the tape? What I'm getting at here is that you showed the SHOW PROC/PARSE for the account you are using to try and restore, but the account used to create the tape may have had the extended parsing turned on. The backup listing will show this. Please supply us with that.

[Kirsten Knüttel]

Hi,

I've used the same account for backup and restore. And it is difficult for me to cut the backup/list output, because, the machine, where I restore the data (system disk included) has no access to anything else at the moment.

Another point I've found out in the last hours is, that the RMU-restore worked fine and found the RBF-files on tape.

So I've found a workaround for the restore of the files, the restore of the DB worked fine now.

I would say, if nobody has an idea why there are problems to find the backup file on tape I would close the thread. But not without saying a big thank you to all who have thought about this problem.

Regards,

Kirsten

[Guenther Froehlin]

Kirsten,

you can't let us hang with this...please! You are doing something we all know works.

One question:

"backup/image $1$dua240: $42$mka300:...
...
backup/image $41$mka400:dua240.bck ..."

It seems you were using two tape drives. Are you sure you used specified the correct drive all the time?

/Guenther

[Guenther Froehlin]

And I see the tape is written on a TZ88 and read on a TZ89. Where did the /LIST work?

You can give it another try. Write one save set on the TZ88. Mount the tape /FOREIGN on the TZ89 and do a "DUMP tape:/BLOCK=COUNT:2/OUT=dmp.log". In dmp.log look at the save set file name after the block which starts with "HDR1". The next 17 characters after HDR1 is you save set name. That's what BACKUP is looking for.

/Guenther

[Jon Pinkley]

This is just a comment, and not a claim that you mistyped. However, DUA240 and DUA24O look very similar, especially in some fonts. Also the zero key is right next to the letter O key, making that an easy thing to mistype.

I have spent a fair amount of time trying to determine why code wasn't working, when in fact it was.

That is the main reason that having machine recorded output of what was typed, and what the error messages were, is extremely beneficial for the debugging process. Many times I find my errors when I am preparing a "trouble report".

I can understand that you may not be able to connect anything the system you were attempting to restore on, (perhaps it is in a secure area). But it would be useful to know if you can reproduce the problem on the system you created the backup on. If it works as expected there, then you can start looking for things that are different in the systems.

As Guenther said "You are doing something we all know works." A workaround should not be necessary, if the correct procedures are used to create and read the backup tapes.

If this is a one-shot transfer of data, then you may not feel it is worth the time to pursue the problem any more. If you are going to be doing this on an ongoing basis (perhaps from a production to a test system), then I would claim it would be worth determining what the problem is, fixing it, and writing a command procedure to make the process as foolproof as possible.

p.s. Some people that learned to type on an old typewriter learned to use a lowercase L for a numeral 1, as many old typewriters had no numeral 1. I don't see this particular substitution happen much any more, I did see it more frequently in the 1980's, and it would show up in reports about the system not sorting part numbers correctly.

Have fun,

Jon

[DECxchange]

Hello,
I see you've gotten a lot of responses, so I hope mine helps and is not redundant to other folks' helpfulness. Anyway, I've had great success on DAT tapes by doing backups in the following way (using your drives' nomenclature):

$ init [/media=compact] $1$dua240: 240bck
$ backup/image/ignore=(nobackup,interlock) $1$dua240: $42mka300:dua240.bck /save_set /label=240bck [/media=compact]
Other notes:
Note #1
-------
If your tape is already initialized and used previously, you can see what save sets are on it by repeatedly doing a
$ backup/list
Then wait for the tape to find the beginning of the first backup. As soon as it starts listing the header of that backup, and the first few files in the save set, hit the hold screen button (or s), then hit c. Now, hit hold screen again (or q). Now at the $ prompt, up arrow to
$ backup/list
and hit return again. Repeat this process and you will see all of the save sets that are on the tape. After the last save set, when you do a backup/list one more time, you will get a message stating there are no more files on the tape.

Note #2
-------
If you DO NOT use the rewind qualifier, you will just append the next save_set to the end of the other save sets, until you run out of tape, then BACKUP will ask you to load the next tape to continue the backup.

Note #3
-------
I always cycle through (using backup/list) each backup tape to the end, when I get the message about no more files to ensure I'm at the end of the tape. Otherwise, if you're somewhere in the middle or at the beginning, you could overwrite backups you or somebody already put on the tape.

Note #4
-------
Don't forget to run a cleaning tape through periodically, or you will get backup errors or the things will appear not to work properly.

Anyway, I hope I've helped and not reanswered somebody else's answer, seeing there are a lot of them! ;)

Greg Miller
DECxchange

[Jon Pinkley]

DECxchange stated specifically that he used DAT drives. I no longer use DAT, but the following should be true independent of the underlying tape types. I have used the following techniques with 9-trk, 8mm, DAT, DLT and LTO.

RE: Note #1
-------
The method given above will work, but requires a lot more manual intervention than

$ mou/for/nounl tape:
$ backup/list=tape_backup.lis tape:*.*
$ dism/nounl tape:

and then opening the tape_backup.lis file with an editor, or using search to find all the saveset names. This also validates that the structure of the backup saveset is correct and readable. It does not validate that the saveset can be restored to valid files. For example, if the backup was created on a disk mounted for shared access and the backup/ignore=interlock switch is used, it is possible to have files that will not be valid when they are restored.

The other method, if you want only the names of the savesets, and don't care about the contents:

$ mou/ov=id/nounl tape:
$ directory /date/size/wid=(file:30,size:7) tape:*.*/out=tape_directory.lis
$ dism/nounl tape:

RE: Note #2
-------
Correct, with the additional note that it will always append at the logical end on tape, so it doesn't just start writing from the current tape position, unless it is already at the logical end of tape.


RE: Note #3
-------

While it certainly doesn't hurt to list all the tape's savesets before appending an new saveset, it should be impossible to overwrite an existing saveset using just the backup command, unless you use BACKUP /REWIND.

The affect of BACKUP /NOREWIND is to first position to the logical end of tape, then write from there.

The only way I know of to overwrite a saveset that isn't the first on the tape is to write directly to the tape or to use something like

$ set magtape/end_of_file tape: ! writes a tape mark

Jon

[Kirsten Knüttel]

Hi,

thank you all for those many responses.
You are right, I'm at the moment in a secure area where I have to rebuild the machine, I run normally, for testing. For this reason, the device names are not the same.
I don't think, that I've typed something wrong, because 2 collegues tried to help me with the problems and I don't think, that everyone of us typed an O instead of a 0.
When I'm back in my normal environment I will do some more tests with backup on one tape and restore from another.

Regards,

Kirsten