T24 Disaster Recovery Validation Checklist

Database recovery versus application-process state

A consistent database restore and recovery should roll back uncommitted database transactions according to the database platform. The remaining T24 risk is not “orphaned uncommitted database transactions”; it is incomplete application or business process state around the recovery point.

Examples include scheduler and job-control records, external messages, files, partially completed workflows, downstream acknowledgements, and business operations that crossed system boundaries. These states must be reconciled separately from database consistency.

1. Infrastructure validation

• Required hosts, storage, mounts, network routes, DNS, certificates, and time synchronisation are available.
• Capacity and performance are sufficient for recovery validation and the expected workload.
• Recovery components are isolated from unintended production traffic until release is approved.

2. Database validation

• Restore and database recovery completed consistently according to the database platform.
• Business date, database identity, recovery point, and expected environment are confirmed.
• Consistency checks, backup chain, permissions, and required database services pass.

3. Application validation

• Application and TAFJ services start in the approved order with no unexplained errors.
• Authentication, read-only enquiries, and an approved controlled transaction path work.
• Versions, configuration, deployed artefacts, and runtime instance match the recovery plan.

4. Integration validation

• MQ, OFS, APIs, file transfers, gateways, and downstream systems remain controlled during validation.
• Queue depth, consumer state, files, acknowledgements, and later external work are reconciled.
• Duplicate, replay, redelivery, and ordering risks are owned before interfaces reconnect.

5. Batch and COB validation

• COB stage, scheduler state, service state, job list, and business date describe the same processing point.
• Incomplete application or business-process state is identified and assigned an owner.
• The restart and verification sequence is documented and approved.

6. Business validation validation

• Balances, reports, statements, files, interfaces, and control totals reconcile.
• Representative users confirm critical journeys and expected data are available.
• Residual gaps, accepted risks, rollback point, and sign-off are recorded.

Controlled COB verification

Do not assume every T24 environment supports a COB “dry run.” Use a dry-run or validation mode only when it is a locally supported, documented capability for the installed release and process.

Otherwise, agree a controlled verification plan: isolate interfaces, confirm the job list and restart point, select representative checks, define stop conditions, capture each stage, and reconcile the resulting outputs before the environment is released.

Evidence pack and sign-off

• Recovery point, components restored, versions, and configuration baseline
• Infrastructure, database, application, messaging, and interface results
• COB stage, business date, outstanding jobs, and restart boundary
• External messages, files, acknowledgements, and reconciliation decisions
• Controlled transaction and business-journey results
• Known gaps, accepted risks, owners, rollback criteria, and approvals

A concise evidence structure is available in the incident escalation checklist. For batch closeout, read why batch success can be misleading.

Release decision

Release the restored service only when the recovery point is understood, validation evidence is complete, interfaces have an approved reconnection sequence, uncertain work has owners, and both technical and business authorities accept the residual risk.

Related reading