Db2u (oltp) Containerized deployments: Enable PIT recovery with snapshot backups

In a Db2u (oltp) deployment on OpenShift, the current snapshot-based backup and restore process (e.g., via OADP/Fusion recipes) exhibits a critical limitation regarding point-in-time recovery (PITR).

Db2u startup scripts automatically resume database write activity by runing RESTART DB WRITE RESUSE if the database is found in a write-suspended state. This behavior effectively restores the database only to the exact state of the snapshot and prevents placing the database into rollforward pending state (using db2inidb). As a result, it is not possible to perform a rollforward recovery to a later point in time using transaction logs.

Testing in a customer-like environment confirmed that:

• Even when only restoring the data volume (with logs stored separately), the Db2u startup process implicitly resumes write activity.
• This makes documented recovery steps (e.g., triggering rollforward pending state) ineffective.
• Workarounds such as uncataloging and re-cataloging the database can technically enable PITR, but are not suitable for production use.

This behavior creates a functional inconsistency between Db2’s core recovery capabilities and its implementation in containerized environments.

Further, in our scenario, we are evaluating the use of an S3 bucket for storing archived transaction logs. When restoring a snapshot into a new environment (e.g., a different cluster), access to the same S3 bucket is also restored.

If an automatic RESTART DATABASE is triggered during startup, the restored environment continues writing to the same archive log location. Since log files use identical naming conventions and no new log chain is created, this leads to a collision between the original and the restored environment. Existing archived log files from the source environment may be superseded or rendered inactive, while new versions with the same names are created.

This behavior introduces a high risk of compromising the integrity and usability of archived logs and can negatively affect subsequent recovery operations.

While it may be possible to mitigate this issue (e.g., by changing credentials for the S3 access), such measures add operational complexity  by changing the running - original - system (maybe production).

Without an automatic RESTART DB action at startup, the user could take other appropiate action on the restored system.

From an operational perspective, the pod could behave in the following way instead:

• Detect when a database is in write-suspend state.
• Avoid automatically resuming write operations - just leave it as is.
• Allow administrators to explicitly decide whether to perform:
  • a simple snapshot recovery (or restart db), or
  • a rollforward to a specific point in time.

Without this flexibility, snapshot-based backup strategies cannot support standard enterprise recovery requirements for Db2u oltp deployments.

Maybe it is possible to switch between the two behaviours with a special annotation or something similar.