LEARN. PRACTICE. GROW.Define what recovery means
Recovering configuration does not automatically recover the service. A profile can start and allow console access while an essential integration remains unavailable. Define the expected outcome beforehand: critical functions, dependencies, operating identity, and data that must remain accessible. In a WebSphere context, identify cell, node, profile, version, and external components used by the application. An archive is only part of that set. Keep file restoration, startup, and functional confirmation distinct in the plan and report. Then, when the console responds but the partner call fails, you can communicate actual progress without declaring complete a recovery that still does not satisfy the business.
Manifest and archive integrity
The fixture contains a readable ZIP with profile/config.xml. Its manifest also declares external/trust.pem, which is absent from the archive. CRC passes because it checks existing members; it does not know which dependencies should be present. In a second experiment, one member byte is deliberately changed without updating CRC, and testzip identifies the corrupt file. These observations distinguish integrity from completeness. Neither establishes cryptographic provenance. The lab uses an original format and does not execute backupConfig or restoreConfig. For an actual WebSphere procedure, confirm tool scope, external dependencies, and recovery requirements in documentation applicable to the installation.
Equal content and different access
A restored file can have correct bytes and the wrong access context. To demonstrate this distinction, the workshop creates two equal copies and explicitly sets modes 0600 and 0644. The latter permits reading by more user classes. A byte digest does not show that difference. The experiment does not claim that ZIP or restoreConfig automatically chooses those modes; they are controlled fixture inputs. In actual recovery, check owner, group, mode, ACLs, paths, and process identity according to the system used. Confirm that the authorized service can read what it needs and that recovery has not broadened access to sensitive material.
Context and changes since rehearsal
The context model compares a trial in test, profile node-a, with a proposal for production, profile node-b. Build 9.0.5.29 matches, but that does not make the environments equivalent. Endpoints, directories, identities, trust, and job effects can differ. Renaming the archive does not adapt internal values. Also record changes since rehearsal: a new LDAP endpoint or another truststore path can invalidate part of earlier evidence. The response is not to declare all recovery impossible, but to analyze differences and validate the actual proposed plan. Control destinations and job activation to avoid unauthorized business effects during practice.
Measure through validated service
In the lesson forecast, stages are sequential: eight minutes for artifacts, five for permissions and trust, four for startup, and six for functional validation. The sum is twenty-three minutes, exceeding the twenty-minute objective. Excluding validation or access to report twelve minutes changes the criterion without solving the problem. These numbers are synthetic, not measured WebSphere timings. In an authorized trial, measure from the defined interruption to the accepted functional outcome, including relevant waits, decisions, and dependencies. Use results to improve the plan or discuss objectives with the business, keeping explicit who can accept risk and change commitments.
Workshop and RUN handover
Run the local checks and write a conclusion for each group: what passed, what failed as expected, and what was not tested. Then prepare an operational guide with prerequisites, context, authorized artifact sources, steps, success criteria, and a way to retreat. Add owners and outstanding work that another person can understand without depending on the author’s memory. In the fictional readiness meeting, present the twenty-three-minute forecast and environment differences as concrete gaps. The lab helps explain those decisions, but RUN autonomy requires authorized rehearsal and human review in the target environment. Keep the course an independent assessment without awarding IBM certification.
# LOCAL ARCHIVE/FILE FIXTURES, not backupConfig or restoreConfig
# ZIP members: profile/config.xml
# Required dependency missing: external/trust.pem
# Equal file bytes; explicitly assigned modes: 0600 and 0644
# SYNTHETIC sequential recovery: 8 + 5 + 4 + 6 = 23 minutes
# Objective: 20 minutes through functional validationThe ZIP passes CRC but an external truststore is missing. Restored XML has matching bytes and a different mode. The console responds, but functional recovery remains unaccepted.
Common pitfalls
Treating CRC as completeness; comparing only bytes; reusing evidence from another profile; ignoring startup jobs; omitting validation from recovery timing.
Related topics: Maintenance and recovery · Topology and configuration · TLS and access
Accept recovery when the required set, access, context, and functional outcome are established within the correct scope.
Reference: Test disaster recovery implementation · BigSavant WebSphere traditional ND 9.0.5; maintenance baseline 9.0.5.29 (2026-09-08); documentation reviewed 2026-09-30