Db2

 View Only

  • 1.  Restore REBUILD danger

    Posted Thu April 08, 2021 09:46 AM

    Hi,

    I am surprised that a RESTORE REBUILD does not control the availability of backups before starting the operation.

    For example, let's assume this sequence:

    - FULL backup

    - FULL incremental backup

    - FULL tablespace backup

    - FULL backup is removed, DBA is not aware about this situation

    ==> The restore rebuild will proceed and your database is scratched.

    Why not testing first backups availability to avoid letting DB in restore pending status ?

    Thanks, JMB


    #Db2
    #Db2EarlyAccessProgram(EAP)Forum


  • 2.  RE: Restore REBUILD danger

    Posted Thu April 08, 2021 09:47 AM
    Hi.  Unfortunately, during the RESTORE REBUILD procedure and the AUTOMATIC INCREMENTAL RESTORE procedure, the initial restore operation restores the target image, which defines the structure of the database that can be restored (such as the table space set, the storage groups and the database configuration).  It is from this step that Db2 can now query the history file to determine what table spaces from what backup images are required.  This step occurs after placing the database in restore pending.

    Ideally, the user should ensure that all backup images in the history file are accessible in the location specified in the history entry.  If the database history file is configured with appropriate retention settings (NUM_DB_BACKUPS, REC_HIST_RETENTN, AUTO_DEL_REC_OBJ) then objects still in the history file (as long as not marked for deletion) should exist.  If objects have been moved from their original location then UPDATE HISTORY should be used to update the location field.  If objects have been manually deleted outside of Db2's knowledge then this can be a problem to future restores if any of those images are required for rebuilding or incremental restore.

    I understand your concern.  Current infrastructure and recovery procedures limit Db2's ability to detect all missing objects upfront.  If doing an incremental restore, you can rely on db2ckrst to determine dependent images beforehand, which you can then verify exist before doing the actual RESTORE.  Unfortunately, this tool is unable to do the same for rebuilding a database, as mention in the Knowledge Center.

    In your scenario above, it could be possible to use the db2ckrst tool for the incremental portion of the restore just to give you some pre-checking.  But, I agree, this is not the easiest step to do and can get more cumbersome for more complex restore scenarios.

    If you would like Db2 to consider some improvements in this area, please consider opening a RFE request so this can be considered in a future deliverable.

    Thanks.
    Original Message


  • 3.  RE: Restore REBUILD danger

    Posted Thu April 08, 2021 09:46 AM

    Hi Mickael,

    Thanks for your detailed long answer.

    For a very long time, I have considered DB2 privileging no data loss, and today, from this REBUILD perspective (or RESTORE INCREMENTAL automatic), we must be carefull before attempting such a RESTORE.

    Now that said, if we regularly do backups, this situation to loose the DB should not happen, but this problem might anyway arise. I don't see why a RFE should be needed here to ask for better security. When not using REPLACE EXISTING, you ask the question if we really want to scratch our DB files, that's good, but I would prefer a warning like : attention do you have all you backup files ? 

    Best regards,

    JMB


    Original Message