#Db2
#Db2EarlyAccessProgram(EAP)Forum

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.

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:
Sent: Mon March 30, 2020 01:18 PM
From: ROBBY SHARMA
Subject: Restore REBUILD danger

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.