Informix

 View Only
  • 1.  verifying ontape archives with archecker

    Posted Mon October 14, 2019 11:49 AM
    This is for IDS 11.70 on HP-UX PA-RISC.

    I am attempting to use the archecker utility to verify that our ontape level 0 archives do not have any issues such as corruption. The Backup and Restore Guide doesn't seem to have any information on this option. There is info on how to do table-level restores using archecker, and the section on the 'onbar -v' option states that it uses the archecker utility, but there is no info on how to use archecker with ontape archives.

    Running the 'archecker -h' command shows that I can use 'archecker -tdvs' to verify an archive using the ontape driver.

    One minor complicating factor is that our archives are gzipped when they are created, via the command 'ontape -s -L 0 -t STDIO | gzip > $ARCHIVE_FILE_NAME'. It's not a big deal when we use the archive for a restore, as ontape reads from STDIN, so we can do 'gunzip --to-stdout $ARCHIVE_FILE_NAME | ontape -r'.

    For whatever reason, archecker does not read from stdin. To get around this, I've created a named pipe my_archive_file, and set AC_TAPEDEV in my AC_CONFIG file to point to that named pipe. If I run the command 'gunzip --to-stdout > my_archive_file' in one window, I can then run 'archecker -tdvs' in another window, the utility seems to check our archive, and it reports that everything is good. The problem is that archecker prompts me to 'Please put in Phys Tape 1', and to 'Type <return> or 0 to end'. It requires that I press <return> before it will do anything. That doesn't work well in a script.

    Is there a way to get archecker to verify an ontape archive without requiring the <return> key be pressed?

    ------------------------------
    Mark Collins
    ------------------------------

    #Informix


  • 2.  RE: verifying ontape archives with archecker

    IBM Champion
    Posted Mon October 14, 2019 11:55 AM

    Try –d However, some versions that doesn't appear to work

     

    Cheers

    Paul

     






  • 3.  RE: verifying ontape archives with archecker

    Posted Mon October 14, 2019 12:08 PM
    I'm using 'archecker -tdvs', so that should include the '-d' option, correct? 

    The 'archecker -h' output says that '-d' will "Delete old archecker metadata files and continue with new verification''.  I guess the 'continue' part isn't working here.

    ------------------------------
    Mark Collins
    ------------------------------



  • 4.  RE: verifying ontape archives with archecker

    IBM Champion
    Posted Mon October 14, 2019 12:11 PM

    My bad the –d is for ontape – misread the question

     

     

     






  • 5.  RE: verifying ontape archives with archecker

    Posted Tue October 15, 2019 10:02 AM
    instead of "piping" standard output to gzip, set in $ONCONFIG this parameters:

    BACKUP_FILTER /usr/bin/gzip
    RESTORE_FILTER /usr/bin/gzip -d

    Then, you can store your backup compressed without further action:
    ontape -s -L 0 -t $ARCHIVE_FILE_NAME
    or
    ontape -s -L 0 -t STDIO > $ARCHIVE_FILE_NAME

    Also archecker should work properly

    ------------------------------
    Vicente Salvador Cubedo
    ------------------------------



  • 6.  RE: verifying ontape archives with archecker

    Posted Tue October 15, 2019 10:02 AM
    I'm not sure my previous message was posted, Just in case I post another ;-)

    Set two parameters in your onconfig file:

    BACKUP_FILTER /usr/bin/gzip
    RESTORE_FILTER /usr/bin/gzip -d

    And create your backup normally. It will be compressed automatically
    ontape -s -L 0 -t  $ARCHIVE_FILE_NAME

    And also archecker should work ;-)

    ------------------------------
    Vicente Salvador Cubedo
    ------------------------------



  • 7.  RE: verifying ontape archives with archecker

    Posted Tue October 15, 2019 10:49 AM
    I don't recall why, but I recall being told there was something that didn't work if you used BACKUP_FILTER/RESTORE_FILTER.  Maybe it was the table-level restore?  Or maybe it was output to STDIO?  It was a few years ago, so maybe that restriction has been removed in later releases, but we haven't upgraded since then, so we're still stuck with whatever that limitation was.

    Anyway, I did add BACKUP_FILTER/RESTORE_FILTER and retried the archecker with 'archecker -tdvs < $ARCHIVE_FILE_NAME' and with 'cat $ARCHIVE_FILE_NAME | archecker -tdvs'.  Both failed.  It's as if it's waiting for the <return> key, but getting the stream of characters from the archive file:

    Please put in Phys Tape 1.
    Type <return> or 0 to end:

     Incorrect input ▒▒I]). Please try again.


    Please put in Phys Tape 1.
    Type <return> or 0 to end:

     Incorrect input (Vr▒▒▒K ▒]>▒▒▒▒SJ ▒▒▒)▒▒ȕb▒▒▒▒rwp▒WI▒▒]{\▒Pr▒▒=c)v ▒▒▒▒Z▒▒▒̎~▒▒ͮ->▒). Please try again.




    ------------------------------
    Mark Collins
    ------------------------------



  • 8.  RE: verifying ontape archives with archecker

    Posted Tue October 15, 2019 11:02 AM
    You're missunderstanding how archecker works. You can't pass your backup file to the standard input of the archecker.

    You need to set up the archecker configuration file usually located in $INFORMIXDIR/etc/ac_config.std  and there you need to configure where the backup file is located.

    For more information see: https://www.ibm.com/support/pages/configuring-archecker-validate-backups-taken-ontape

    ------------------------------
    Vicente Salvador Cubedo
    ------------------------------



  • 9.  RE: verifying ontape archives with archecker

    Posted Tue October 15, 2019 12:57 PM
    I didn't (originally) think that I could pass it as stdin, which is why I was using a named pipe instead.  I switched to using stdin based on what I thought you were saying earlier.  I must have misunderstood your prior comment.

    I do have an ac_config file, and have set the AC_CONFIG environment variable to point to it.  When the AC_TAPEDEV parameter is set to the named pipe (full path name to the named pipe) and I use 'gunzip --to-stdout $ARCHIVE_FILE_NAME > my_named_pipe', archecker appears to work, although it first displays several lines of configuration info and then requires that I press the <return> key to get things started.  Once I press <return>, I get the many lines of dots indicating progress, followed by a listing of the various tablespaces that were validated, with SUCCESS messages.

    Maybe I'm misinterpreting what you were getting at in your most recent message, but I tried setting AC_TAPEDEV to point to the specific file that contains the level 0 archive.  In other words, I set it to the same value as $ARCHIVE_FILE_NAME, which includes the full path.  When I ran 'archecker -tdvs' with that setup, I got:

    Please put in Phys Tape 1.
    Type <return> or 0 to end:

    Failed tape page check.
    Failed tape header/sanity check.

    Please put in Phys Tape 1.
    Type <return> or 0 to end:

    Failed tape page check.
    Failed tape header/sanity check.


    This is with the same level 0 archive that appears to pass when used with the named pipe method.

    I also tried setting AC_TAPEDEV to point to just the directory that contains the level 0 archive file.  When I ran archecker that time, it errored out, indicating that it was looking for a file named <servername>_<servernum>_L0.  I renamed my existing archive to match that naming style and ran archecker, and it did start without the need for me to press <return>, but it generated the following output:

    AC_STORAGE /tmp
    AC_MSGPATH /tmp/ac_msg.log
    AC_VERBOSE on
    AC_TAPEDEV /test_backup/dev_test/L0_archive/
    AC_TAPEBLOCK 32 KB
    AC_LTAPEDEV /test_export/dev_test/log_backup/
    AC_LTAPEBLOCK 32 KB
    AC_RESTORE_FILTER /usr/contrib/bin/gunzip
    AC_TIMEOUT 300
    AC_SESSION
    Archive file /test_backup/dev_test/L0_archive/gasmi300_200_L0
    Failed tape page check.
    Failed tape header/sanity check.
    Archive file /test_backup/dev_test/L0_archive/gasmi300_200_L0
    Failed tape page check.
    Failed tape header/sanity check.
    Archive file /test_backup/dev_test/L0_archive/gasmi300_200_L0
    Failed tape page check.
    Failed tape header/sanity check.


    Again, this is with the same level 0 archive that appears to pass when used with the named pipe method.

    I did read the link that you included.  That link shows that the user is prompted with the message:

    Please put in tape number 1.
    Type 1 <return> or 0 to end:1


    It's interesting that their example has slightly different text, asking the user to 'Type 1 <return> ...', where mine simply says 'Type <return> ...'.  But it's that requirement to type some sort of input to start the validation that I'm trying to get around.  So the method of setting AC_TAPEDEV to the directory, and having the archive file match the prescribed naming convention, appears to be the correct direction.  The problem is that it doesn't seem to like the archive file when using that method.

    BTW, I should point out that the archive file in question has been used successfully to restore the instance on another host, so I know the archive is valid.


    ------------------------------
    Mark Collins
    ------------------------------