A builder website restore drill rebuilds a chosen backup at a separate test destination and checks the recovered buyer paths. Inventory the files, settings, account evidence and external dependencies first. Keep live connections disabled. Record expected and observed results. Have a reviewer accept the evidence before calling the rehearsal complete.
What must a builder backup contain?
Start a recovery inventory before opening the archive. Give each asset a source location, version, responsible role and recovery instruction. Record what the backup excludes. A folder containing public pages may leave unanswered questions about editable content, original photography or inquiry handling.
Use this AgAI Labs worksheet as a proposed practice for your team. The builder website maintenance plan identifies the changes that should update your recovery inventory.
| Asset category | What to identify | Evidence to retain |
|---|---|---|
| Content | Published pages, editable source, content exports and download files | Release identifier, page list and approved document revisions |
| Media | Original images, published crops, video files and usage permissions | File inventory, version references and permission record locations |
| Configuration | Build instructions, required software versions, redirects and environment setting names | Configuration revision and instructions for creating safe test settings |
| Domains | Registration, hosting association and recorded domain configuration | Company control evidence and responsible roles, with no domain changes during rehearsal |
| Account ownership | Hosting, content system, analytics and recovery responsibility | Restricted ownership records and the authorized handoff procedure |
| Form dependencies | Handlers, field mappings, mail routes, CRM connections and tracking scripts | Dependency diagram and a replacement stub for each live connection |
Keep passwords, tokens, recovery codes and personal inquiry records out of the worksheet. Reference their approved custody procedure without copying their values. Use synthetic content exports if the real export contains private records. Missing ownership evidence remains an open item, even when the page files are readable.
The owned website and MLS listing guide explains the underlying ownership boundaries. This drill tests a recovery copy of the website record.
Where can you rehearse without changing the live site?
Choose a separate destination that the technical owner can isolate before loading the backup. A local test environment can suit a static site. A site with server functions may need a separately configured test environment. Have the responsible technical person confirm that it cannot write to production systems.
Keep the rehearsal private and clearly labeled. Use synthetic content only. Disable outbound mail, tracking, advertising tags, real CRM connections, scheduled tasks and synchronization. Replace inquiry handlers with local stubs that return a test receipt. If a script needs an external service, block that connection and record its untested behavior.
Changing a form label does not establish isolation. Check its actual destination and any background connections before using the test copy. If isolation cannot be demonstrated, stop before running the restored site. Do not import production credentials to make an incomplete rehearsal appear successful.
- Declare the scope. Record the drill identifier, backup version, chosen pages, operator, reviewer and exclusions.
- Inspect the recovery source. Compare its file list and recorded checksums with the inventory. Keep the original archive unchanged.
- Prepare isolation. Confirm separate storage and configuration. Verify that live destinations and scheduled operations are disabled.
- Restore the copy. Follow the recorded build or import instructions using test settings. Record any missing dependency or manual substitution.
- Exercise the chosen paths. Compare each expected result with direct observation. Capture evidence under its test identifier.
- Close the record. Assign exceptions, obtain review and document cleanup of the isolated destination. Leave production traffic unchanged.
The Owned website stage provides the broader website context. This rehearsal does not authorize a hosting change, domain transfer or production release.
What proves the restored site works?
Write expected results before testing. Choose representative paths from the approved page inventory. Include homepage to plan, project to related plan, process to inquiry, and a document download. Include a page with images and a route that should redirect. Compare content and revision labels with the selected backup.
Use a local inquiry stub to test field handling, required-field errors and the displayed test receipt. Record whether the stub received the expected synthetic fields. Keep mail, CRM delivery and live analytics explicitly untested. An on-screen success message alone does not prove an external destination received anything.
NIST SP 800-34 Rev. 1, section 3.5.1, discusses recovery testing with explicit objectives and success criteria. Section 3.5 describes recording results and corrective actions. Its guidance addresses federal information systems. The builder worksheet below is a proposed adaptation, not a NIST template or certification.
| Asset | Recovery source | Version | Isolated destination | Expected behavior | Observed result | Reviewer | Exception |
|---|---|---|---|---|---|---|---|
| [asset or path] | [archive reference] | [release or revision] | [test location] | [specific check] | [pass, fail or unresolved; evidence reference] | [reviewer role] | [issue, owner and next check] |
Fictional worked example: A synthetic builder site uses archive SAMPLE-R4 and a private local destination labeled DRILL-A. These labels describe an invented exercise. They do not report a client result or an AgAI Labs recovery service.
| Asset | Expected behavior | Observed result | Evidence and disposition |
|---|---|---|---|
| Plan and project pages | Project links to the matching plan with its approved image | Pass: local pages and image agree with SAMPLE-R4 | Capture E-01; content reviewer checked |
| Specification download | Open synthetic document revision D4 | Fail: backup contains revision D3 | Capture E-02; content owner must supply D4 |
| Local inquiry stub | Reject missing required field; accept complete synthetic fields | Pass: both local responses match expectations | Receipt E-03; no mail or CRM delivery tested |
| Account handoff record | Locate ownership evidence and responsible recovery role | Unresolved: hosting ownership reference absent | Record E-04; account owner must provide evidence |
The fictional reviewer records the overall outcome as incomplete. Successful page rendering does not close the document failure or the ownership gap. The next attempt must identify the corrected recovery source and repeat the affected checks.
Which dependency failures stop the drill?
Refuse to start if the archive is missing, its version cannot be identified or the isolated destination still reaches production. Refuse the affected recovery check if a required file, decryption capability, software dependency or configuration instruction is unavailable. Record the precise gap instead of substituting an unapproved public file.
Stop immediately if the restored copy attempts an outbound message or a production write. Record what was attempted and ask the technical owner to resolve isolation. Keep the record incomplete until a fresh check proves the boundary holds.
Some exclusions can remain documented without blocking unrelated local checks. A disabled analytics connection, for example, leaves reporting untested. It does not prevent a plan-page inspection. Mark each row separately so nobody reads a partial rehearsal as full recovery acceptance.
Who signs the recovery record?
The operator records what was restored. The content reviewer checks representative pages and documents. The technical reviewer checks the test boundary, configuration and observed behavior. The builder's designated owner accepts the stated scope and assigns unresolved work. Record the responsible people privately; public examples can use role labels.
Attach a short acceptance record: drill identifier, date, recovery source, destination, tested scope, exclusions, evidence locations, outcome and signatures. Give each exception an owner and a condition for retesting. Keep the record with the Handoff runbook and ownership evidence.
Drill ID and date: [identifier; date] Recovery source and version: [archive; release] Isolated destination: [test location] Tested scope: [worksheet row identifiers] Excluded behavior: [live connections and other omissions] Evidence location: [restricted record reference] Outcome: [complete within scope; incomplete; stopped] Exceptions: [issue; responsible role; retest condition] Operator: [signature; date] Content and technical reviewers: [signatures; dates] Designated owner: [scope acceptance; signature; date] Test destination cleanup: [status; responsible role] Production cutover authorization: separate decision required
Accept only the scope the evidence supports. Production cutover needs a separate authorized plan covering traffic changes, live dependency checks and reversal. Leave provider-specific restoration commands and account operations to authorized people.
What else should you record about a restore drill?
Can a screenshot prove the backup is recoverable?
A screenshot proves only the captured display. A builder website restore record also needs the recovery source, version, isolated destination and observed checks. Preserve failures and exclusions beside successful captures.
Should a restore drill send a real inquiry?
Use synthetic fields and a local inquiry stub for an isolated restore drill. Keep real mail and CRM connections disabled. Delivery checks require separate authorization and a controlled plan.
Does a completed drill authorize a domain switch?
A completed builder website restore drill accepts only its recorded rehearsal scope. Switching production traffic requires a separate authorized cutover plan and checks of the live dependencies.
When should the recovery record be revisited?
Revisit a builder website recovery record when its source files, software, hosting, ownership or inquiry dependencies change. Use the maintenance owner to identify affected rows and arrange another scoped rehearsal.