/backup/list how to (error)

[Jon Pinkley]

What was in the first part of the record? That's where I would have expected the original backup command to have been. If it was like what you have displayed, then it certainly doesn't look like a recoverable saveset.

Do you know where the file came from? It is possible this was originally an on disk backup saveset that was marked /nobackup so it wouldn't take up space on normal backups, and then somewhere along the way, someone migrated from one disk to another using backup/image without specifying /ignore=nobackup. Once that happened all chances of recovering the data from the new file are gone.

Is there another copy of the backup saveset another system? It appears to have been created today, and the recordsize is consistent with a file FTPed in binary mode, so can you go to the original system and do a directory/full there? If it is showing up with "File attributes: ... Backups disabled", and you can't get backup/list to work there, then you are out of luck unless you can find a copy on tape that was made before the saveset was marked /nobackup. Or you can find the original disk. Given the filename, it appears this is from quite some time ago.

Summary: To see what you should expect to see from the dump of the backup saveset, create a saveset and dump it.

Example attached

[Steven Schweda]

> If the FIXREC program didn't work, then the
> original backup saveset may not have had a
> blocksize of 32256.

As it says on the Web page cited above, _my_
version if the FIXREC program "reads the file
to determine the BACKUP save set's original
block size."

I don't see anything in my Web server log to
suggest that anyone has downloaded the
program recently, so I'd tend to believe that
the original inquirer has not tried it.
(There was one look at the page from a ".id"
domain, referred from this forum page, but
nothing past the cited page -- nothing
containing the program in any form.)

Show me the output from FIXREC, and I'll
think harder about the problem. Or the
_beginning_ of the DUMP output where the
block size should be, like the "7E00" (32256)
here (DUMP /WORD /RECO):

0000 0000 0000 0001 0001 0001 0800 0100 ................ 000000
0000 0000 0000 0000 0000 0000 0000 0000 ................ 000010
0000 0000 0000 7E00 F5FC 178C 0001 0101 ......üõ.~...... 000020
0000 0000 0000 0000 6361 622E 7069 7A07 .zip.bac........ 000030
[...]

[Hein van den Heuvel]

Jokos.,

Welcome to the HP ITRC Forum.

Your file can 99% certain be fixed as it clearly has the broken file attribute.

You do have to wonder about the system you inheritied. Did this ever work? Did you miss out on some hand over instructions? Is there local support avaiable? Get ready to engage in some (on the job) traiing or consulting or heavy duty manual and help-text reading.

Now go back to that very first reply.
Read it.
Good.

Now read it again and DO IT.
No, noone will do this for you.

So now you read the referenced site.
Read it again and DO IT.

If you have no C compiler, then you can look at a MACRO alternative at this site:
http://www.openvms.org/phorum/read.php?1,4592
Be sure to read the context. Do you recognize the problem and advices?

You would need to figure out where the macro code starts and ends; cut it; paste it into a file called for example FIXSAVSET.MAR; compile it: $MACRO FIXSAVSET; link it: $LINK FIXSAVSET; run it $RUN FIXSAVSET or MCR dev:[dir]FIXSAVSET SYS$GENERAL5:[000000]RPRSYJUL1991.BCK;1

Good luck!
Hein van den Heuvel.

[Hein van den Heuvel]

Jon,
>> This should have the original backup command used to create the saveset.

Yeah, but the blocksize might not have been specified.
Also I would recommend to suggest DUMP/BLOC=COUNT=1
Makes not difference in this case, as the record size was 512, but if it is 32K...
We just want to see the hex word at byte 40.

Steven,
Reply collision!
I peaked at the site before re-recommending it.
Should have come from xxx.east.verizon.net.

Jokos,
As an alternative to the DUMP, you can use the read-only version of my fixsavset.com as per below.
Cut out; paste into .com file; execute with @.

Hein.


$!---------------------------- read_only_fixsavset.com ----------------
$IF p1.EQS."" THEN INQUIRE p1 "Save set file name ?"
$IF f$search(p1).EQS."" THEN EXIT
$IF F$FILE(p1,"MRS").GT.512 THEN GOTO no_can_do
$OPEN/READ file 'p1
$READ file record
$CLOSE file
$mrs = F$CVSI(40*8,32,record)
$WRITE SYS$OUTPUT "Backup blocksize used was: ",MRS
$EXIT
$no_can_do:
$type sys$input

The record size for the selected file is larger than 512.
This script cannot be used for that file.

$exit

[Jon Pinkley]

Steven Schweda,

I looked at the cited page and stopped reading after the first paragraph of the obsolet section. If I would have continued I would have seen that the improved version automatically determined the original blocksize.

I also downloaded, compiled the FIXREC.C_DECC on AXP and verified it works. Nice tool for this specific problem.

Hein,

Yes I agree that dumping the the first two records probaby isn't required, and with Steven's improved fixrec, it isn't needed. However, I know nothing about what tools Joko has at his disposal, therefore I gave a way to fix things with standard tools available on VMS 5.5-2 (dump,copy),

Joko, even if you don't have a C compiler, Steven's FIXREC.ZIP has ready to run VAX images. You will need a VAX version of unzip.exe

unzip the fixrec.zip file, set def [.fixrec] then

$ mc []fixrec.exe_decc SYS$GENERAL5:[000000]RPRSYJUL1991.BCK;1

if it is a valid backup saveset, that should report something like:

SYS$GENERAL5:[000000]RPRSYJUL1991.BCK;1
Using BACKUP record size of 32256.
Old record size: 512
New record size: 32256

Then you should be able to use your original backup/list command.

If that doesn't work, then the .bck file has more problems than just the incorrect recordsize.

You seem to be doing well for someone with one week of VMS experience. Keep using the VMS help command. If you don't have hardcopy documentation, you might want to download the .pdf of the VMS User Guide and read it when you aren't busy with other tasks.

Have fun learning VMS,

Jon

[Steven Schweda]

> You will need a VAX version of unzip.exe

Actually, not. Plain executables are also
available in the directory linked to, but a
little more curiosity may be required to find
them, as I provided a link to the directory
instead of providing links to every file in
the directory from the main Web page. (Also
object files, in case a local LINK might be
needed.)

And, of course, binary FTP shouldn't damage
the executables (or the object files) enough
to keep them from working. And if we assume
that the original problem was caused by a
binary FTP transfer to the VAX, it seemed
reasonable to assume that my first response
was (or should have been) adequate. But, if
you don't follow any of the links, you may
not find much. "You can lead a horse to
water, but you can't make him drink."
(Although I like the Dorothy Parker
formulation better.)

[Joko Subuh Sas]

Dear All,

Before Thanks alot for all to Help me,
Im Still from Manager send the Original Files *.BCK, i feel is wrong/something for the files (*.BCK) coz copied used Samba.


Joko Subuh Sas.

[Steven Schweda]

I know what binary FTP will do to a file. I
do not know what Samba will do to a file. I
can't be sure, but the error messages in your
first posting look as if the FIXREC program
may fix the problem.

Did you try the FIXREC program? What did you
do? What happened?

Perhaps you should explain how this file got
to where it is.

[Verne Britton]

You have not mentioned what real problem you are trying to solve ... just curious :-)

Or is reading the saveset with BACKUP/LIST an exercise as you are just learning about VMS ?


Verne

[Volker Halle]

Jokos,

please do not cross-post questions in different forums without telling so.

http://www.openvms.org/phorum/read.php?6,4618

Please provide the full output of the command:

$ DUMP/BL=COUNT=1 RPRSYJUL1991.BCK

Volker.