Add header to backup save set

[Brad McCusker]

Dan - I am going to be direct here.  You will need help to recover these files.  Our firm can do it for you.  I believe my e-mail address is in my profile, otherwise there is a contact us form on the web site.

Best Regards

Brad McCusker

Software Concepts International

www.sciinc.com

[Dennis Handly]

>I believe my e-mail address is in my profile

Nobody else can see that private info.

[Dan Mellem]

I'm going to ask them if they can provide as much of the backup file as possible to see if I can do anything with that. In the interim, they've provided a raw file from backup that looks closer to what's needed. However, the header is of course missing. I've tried to change some of the attributes to see if I can read it, but haven't had luck. I've tried:

$ set file/attributes=(org:rel,LRL=144,RAT:CR) ace97121.dbm

$ DUMP/HEADER/BLOCK=COUNT=0 ace97121.dbm

%DUMP-E-OPENOUT, error opening DBM_DISK:[DS.DATA]ACE97121.DBM;1 as output
-RMS-F-IFA, illegal file attributes detected (file header corrupted)
-RMS-F-BKS, bucket size too large (FAB)

A newer year file:

VAX1> DUMP/HEADER/BLOCK=COUNT=0 ace04121.dbm


Dump of file DBM_DISK:[DS.DATA]ACE04121.DBM;1 on  2-MAR-2015 14:29:46.79
File ID (18,1,2)   End of file block 100 / Allocated 100

                             File Header

Header area
    Identification area offset:           40
    Map area offset:                      100
    Access control area offset:           243
    Reserved area offset:                 255
    Extension segment number:             0
    Structure level and version:          2, 1
    File identification:                  (18,1,0)
    Extension file identification:        (0,0,0)
    VAX-11 RMS attributes
        Record type:                      Fixed
        File organization:                Relative
        Record attributes:                Implied carriage control
        Record size:                      144
        Highest block:                    100
        End of file block:                101
        End of file byte:                 0
        Bucket size:                      5
        Fixed control area size:          0
        Maximum record size:              144
        Default extension size:           5
        Global buffer count:              0
        Directory version limit:          0
    File characteristics:                 Contiguous best try
    Map area words in use:                2
    Access mode:                          0
    File owner UIC:                       [SYSTEM]
    File protection:                      S:RWED, O:RWED, G:RE, W:
    Back link file identification:        (11,1,3)
    Journal control flags:                <none specified>
    Active recovery units:                None
    Highest block written:                100

Identification area
    File name:                            ACE04121.DBM;1
    Revision number:                      73
    Creation date:                        29-SEP-2003 08:29:01.52
    Revision date:                        16-JUN-2004 15:41:19.54
    Expiration date:                      <none specified>
    Backup date:                          <none specified>

Map area
    Retrieval pointers
        Count:        100        LBN:        424

Access Control List
    (IDENTIFIER=DS$OPERATOR,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL)
    (IDENTIFIER=DS$USER,ACCESS=READ+WRITE)

Checksum:                                 13253

Is there an easy way to copy the header from the newer file over the old one to see if that helps?

Thanks,

-Dan

[Volker Halle]

Dan,

please closely look at the error message:

-RMS-F-BKS, bucket size too large (FAB)

and the dump of the file header of a current file:

Bucket size:                      5

You could change the bucket size with $ SET FILE/ATTR=(BKS=5) ace97121.dbm

and try again...

Remember that I wrote, that certain OpenVMS files cannot be correctly delivered on a 'NTFS disk' ! But you may be able to repair them.

Volker.

[Dan Mellem]

Thanks. Setting the bucket size made it readable. This process seemed to work:

$! Copy file onto the VAX as binary, then:

$! Get data from an existing file

$  DUMP/HEADER/BLOCK=COUNT=0 ace04121.dbm

$! Set attributes to recovered file

$  set file/attributes=(org:rel,LRL=144,RAT:CR,BKS=5) ace97121.dbm

We then reindexed and reordered the data.

We're still going to ask for the BCK file since doing this file-by-file will take a long time, but this is a viable approach.

Thank you all for your help. Once I get the rest of the files we'll try this with the rest of the files and see if we have a complete database. Unfortanately they can only deliver the files on a Windows disk so we're stuck with this process unless we can get the partial BCK file working.

-Dan

[abrsvc]

If the saveset was actually created with version 5.5-2, I have a machine available wit that version.  Backup on newer versions should be able to read and expand the older savesets without problems, but if needed, let me know.

Dan

[Dan Mellem]

Hi, Dan,

Thanks for the offer but we've been successful in restoring other year-end backups on our 6.2 VAX.

-Dan