Recovery ownership
The client owns database backups, protected installation backups, replacement infrastructure, DNS, certificates, and the recovery decision. Assign a database restore owner, host restore owner, network owner, OneView validator, and incident decision-maker before recovery begins.
Use a compatible database and protected installation backup as one coordinated recovery set. Do not mix recovery points merely to make the application start.
Stabilize
- Isolate the failed or untrusted host and stop integration traffic.
- Preserve evidence according to client incident policy.
- Prevent the same installation from running on another host.
- Select a known compatible recovery point and record its OneView version.
- Confirm the required database, installation, certificate, and secret-recovery owners are available.
If only generated settings or permissions appear damaged and the host remains trusted, begin with Installation diagnostics & repair.
Restore
- Prepare a supported host with the required architecture, time, storage, and network access.
- Keep the failed host isolated.
- Restore the complete protected installation backup using the client's approved secret-handling process.
- Restore the matching database recovery point and verify database availability and backup integrity.
- Use the approved OneView recovery/start procedure for the exact recovered release.
- Generate a sanitized installation report.
- Restore and validate the approved HTTPS address.
Do not run initial setup over the restored installation, substitute a different software version, fabricate a missing installation identity, or start the same restored installation on two hosts.
Validate before return to service
- Confirm the expected version and healthy application status.
- Verify database connectivity and the recovered data point.
- Open the approved HTTPS URL and run network checks.
- Sign in with a named administrator.
- Review and revoke restored sessions when the backup age or incident scope makes them untrusted.
- Confirm license state, roles, service accounts, branding, vendor connections, and activity history.
- Rotate credentials affected by the incident.
- Run approved synthetic verifications.
- Reconcile requests accepted after the selected recovery point.
Escalation evidence
Provide only the sanitized report, expected version and architecture, recovery-point timestamps, safe health facts, failure stage, and the smallest client-reviewed redacted log excerpt.
Never send database exports, unrestricted logs, configuration contents, credentials, setup or activation values, certificate private material, vendor credentials, or KYC data.
Return-to-service checklist
- Failed host isolated and duplicate operation prevented.
- Compatible database and protected installation recovery points selected.
- Database, host, network, validation, and incident owners assigned.
- Exact recovered version and approved recovery procedure confirmed.
- Coordinated recovery set restored.
- Application, database, HTTPS, license, access, activity, and synthetic checks passed.
- Restored sessions and affected credentials reviewed.
- Data-loss or reconciliation window recorded.
- Return to service jointly approved.