Can Your Self-Hosted Application Rebuild Its Search? An Operational Readiness Checklist

Search is an operational dependency, not just an interface feature

Search can look like a standard application feature: a box in the header, a filter on a records page, or a way to find text inside uploaded files. Operationally, it may be a separate system with its own data, configuration, processing jobs and failure modes.

That distinction matters during a restore, migration or incident. Restoring the primary database may restore users, records and document references, yet leave search empty, stale or incomplete. A separate search service may require a snapshot restore, a rebuild from source records, or both. File search may additionally depend on accessible attachment storage and text extraction tooling.

Treat search as recovered only when users can find the appropriate records and document content, while users without permission cannot discover protected information through results, snippets, counts or highlights. A service responding to queries is not, by itself, evidence of a recovered search experience.

• Define search as a dependency in the application recovery plan, alongside the database, file storage, identity and network configuration.
• Set a recovery objective for usable search, not merely for the search process starting.
• Assign an owner for search recovery decisions, rebuild execution and acceptance testing.
• Document whether search is needed for routine work immediately after recovery or can be restored in a later phase.

Map the entire search path before deciding what to back up

Start with a data-flow map rather than an assumption about a product’s architecture. For each searchable item, trace how it becomes a result. The authoritative record may reside in a relational database; an uploaded binary may reside in a file volume or object storage; extracted text may be stored separately; and an index may be held in the database or in a dedicated search cluster.

Also identify the query path. The application may query its own database, submit a request to a separate search service, apply permission rules in the application, or rely on indexed access-control attributes. Those details determine whether a rebuild is feasible and where a permission failure could expose data.

A useful map distinguishes the durable source of truth from derived artifacts. It should cover both structured records and attachments, because restoring metadata about a file is not equivalent to restoring the file or the text previously extracted from it.

• Authoritative records: Which database tables, collections or APIs hold the canonical title, body, status, owner and access data?
• Attachments: Where are original files stored, and are they included in the application backup and restore procedure?
• Extracted content: Is text generated at upload time, saved in primary storage, saved in the search system, or generated only during indexing?
• Index: Is it a database full-text index, a separate search-engine index, or a combination?
• Processing: Which workers, queues, webhooks, scheduled jobs or manual commands create and update index entries?
• Query service: Which component executes searches, and what configuration, credentials and network path does it require?
• Authorization: Where are record-level, document-level and field-level restrictions enforced?

Classify the index: authoritative, derived or partly derived

The central recovery question is not whether an application has an index. It is whether the index can be recreated from retained, accessible source data at an acceptable cost and within an acceptable time.

A derived index can generally be rebuilt when the canonical records, files and required transformation rules are retained. A search snapshot may still be valuable because it can shorten restoration, preserve operational configuration or avoid a large rebuild. But it is not the sole copy of business data.

An authoritative or partly authoritative index needs more scrutiny. It may contain enriched text, embeddings, historical data, permissions, annotations or other material that cannot be regenerated from the restored application data. If that information is necessary for correct search, the index and its associated configuration become backup-critical. Do not assume a search-engine snapshot contains every dependency: external files, application databases and external identity or authorization information may remain outside it.

For dedicated search clusters, configuration matters as well as documents. Elastic documents that snapshots can include data, configuration and internal feature data, depending on the use case. Conversely, Elastic’s Reindex API requires retained source documents with _source enabled and does not copy source index settings or templates to the destination. A rebuild runbook must therefore identify the intended mappings, shard and replica choices, templates and ingest configuration before work begins.

• Derived: all searchable content and access attributes can be regenerated from primary records and retained files.
• Authoritative: some required searchable content or metadata exists only in the index or its snapshot.
• Partly derived: core records can be rebuilt, but enrichment, extracted content, ranking signals or access data may not be reproducible.
• Unknown: no owner can show the source, transformation and rebuild procedure. Treat this as a pre-adoption or pre-production gap.

Inspect indexing triggers, queues and failure handling

An index rebuild often fails not because the search engine is unavailable, but because the process that feeds it never runs or silently drops work. Identify every event that should create, update or remove a searchable item: record creation, edits, attachment uploads, permission changes, moves between projects or spaces, deletion and retention actions.

Then identify how those events are delivered. An application may index synchronously during a user request, place work onto an asynchronous queue, run a scheduled job, or require an administrator command. Each model has distinct recovery implications. Queued work needs a clear policy after a restore: replay it, discard it and perform a full rebuild, or restore queue state if that state is required and trustworthy.

Failure behavior deserves a direct test. OpenSearch documents that a failing ingest processor stops the pipeline by default and the document is not indexed, while optional failure handling can change that behavior. Its documentation also describes failure logging and ingest metrics with failed counts. Whatever the chosen technology, operators need an observable answer to: how many items were submitted, succeeded, failed, retried and remain pending?

• List every indexing trigger, including permission and deletion changes.
• Record the worker or scheduler responsible for each trigger and how it is started after restoration.
• Determine whether queues are durable, backed up and safe to replay after a restore.
• Find the error logs, metrics or status views that identify failed and pending indexing work.
• Define retry behavior and the escalation path for permanently failed items.
• Test whether a deleted or access-restricted item is removed or updated in search promptly.

Test permission-filtered search as a data authorization control

Search authorization must be assessed at the result level. A user may log in successfully and hold an appropriate broad role, yet still receive a title, snippet, highlight, result count or attachment text for a specific record they are not allowed to access.

OWASP ASVS calls for explicit permissions for specific data items and authorization enforcement at a trusted service layer, including rules for data-specific and field-level access. Apply that principle to the full search experience, not only to opening a result after it has been displayed.

This is particularly important after a rebuild. If permission data is indexed, it may be stale or missing. If filtering happens in the application, verify that every query path applies it. Check global search, advanced search, autocomplete, saved searches, exports, APIs, background notifications and any AI or retrieval feature that consumes search results.

• Create test accounts representing a normal user, a manager, an administrator and an external or restricted user where relevant.
• Seed or identify records with deliberately different access rules, including a restricted attachment.
• Search for unique terms from protected titles, body text and file contents.
• Verify that unauthorized users see no result, snippet, highlight, count or suggestion that reveals protected content.
• Change access to a known item, then measure and verify how the change reaches search.
• Repeat tests after a restore and after a full index rebuild.

Include attachments and text extraction in the recovery design

File search is a separate recovery problem from record search. An application may index only file names and metadata, or it may extract body text from supported documents. In the latter case, successful reconstruction depends on the original binaries being available, readable and supplied again to the extraction process when required.

OpenSearch’s ingest-attachment plugin is one example of this pattern: it uses Apache Tika to extract content and metadata from files, which can then be stored in an attachment field. Apache Tika’s format documentation makes clear that support is format-specific and distinguishes metadata and textual-content extraction. Your test set should therefore represent the files people actually rely on rather than only a convenient text document.

Extraction policy affects completeness. The OpenSearch attachment processor has an extracted-character limit that can be configured; a different limit can change what becomes searchable. Record such limits and the resource implications of any change. Also document treatment for encrypted files, scans without usable text, corrupted uploads, uncommon formats and files rejected by policy. A rebuild cannot recover text that was never extractable, never retained or never successfully indexed.

• Restore and verify access to the original attachment store before declaring file search recoverable.
• Maintain a representative test corpus: common office documents, PDFs, plain text, spreadsheets, presentations, scanned files and important specialist formats used by the team.
• Record supported and intentionally unsupported formats, plus the expected behavior for each.
• Record extraction limits, language settings where applicable, and any size or security restrictions.
• Test a known phrase near the end of a long representative document to detect truncation.
• Measure failed extraction and indexing counts separately from successful metadata indexing.

Run a search recovery test that measures usable recovery

A written backup statement is not evidence that search can be recovered. NIST SP 800-184 emphasizes recovery planning, playbook development, testing and improvement. Put search into that cycle with a repeatable exercise.

Use an isolated and authorized test environment. Restore the primary application data and attachments from a selected recovery point, restore or recreate the search service and its configuration, then follow the documented rebuild or snapshot-restore path. OpenSearch notes that cluster snapshots take time and are not perfectly simultaneous views of a live cluster, so define what consistency boundary is acceptable and how you will handle changes occurring during backup activity.

The test should end with evidence, not a green process status. Compare expected and actual results for a controlled sample of records and attachments. Confirm both positive results for authorized users and absence of protected results for unauthorized users. Record the elapsed time to restore primary data, make search infrastructure ready, complete indexing, clear any backlog and pass validation. That total is the practical recovery window for search.

• Choose a recovery point and document its time and expected data boundary.
• Restore canonical records, user and authorization data required by the application, and attachment storage.
• Restore the search service from a snapshot or rebuild it from retained sources, according to the documented design.
• Reapply required index templates, mappings, ingest pipelines, settings and access configuration before or during rebuilding as appropriate.
• Track item totals, queue depth, processor failures and completion status throughout the exercise.
• Validate exact-term searches for known records, expected attachment phrases and changed or deleted items.
• Run permission tests across all material query paths.
• Record elapsed times, exceptions, manual interventions and unresolved gaps; update the runbook before the next test.

Put search services and configuration into backup, migration and change records

Whether an index itself needs a backup is a design decision, not a universal rule. A fully derived index with a tested rebuild may be recreated rather than backed up as the main recovery path. A large index, a slow extraction process or a partly authoritative index may justify snapshots to reduce downtime or preserve information that cannot be recreated.

If snapshots are used, include the items that make them usable. Elastic notes that snapshots can preserve configuration and internal feature data, while loss of system indices or cluster state can mean loss of configuration and feature state. Verify exactly what the selected snapshot scope includes in your deployment, rather than applying a generic assumption. For OpenSearch, account for the fact that snapshot timing is not a perfectly simultaneous point-in-time view.

The same inventory supports migrations and change management. A change to mappings, analyzers, ingest pipelines, extraction limits, queue behavior, permissions or retention policies can alter search quality and recovery behavior. Capture the desired configuration in a controlled, reproducible form and update the recovery runbook whenever the search design changes.

Airbip provides managed deployment for catalog applications as Docker workloads on Airbip cloud servers, along with service lifecycle management and configurable daily, weekly and monthly backups. Those capabilities can support the infrastructure side of an application deployment. The application team still needs to determine what its chosen application stores, how its search is built and who validates recovery of data, attachments, permissions and search behavior.

• Inventory database backups, attachment backups, search snapshots, configuration exports and secrets or credentials required by the recovery procedure.
• Document retention, recovery-point expectations and restore ownership for each artifact.
• Record compatibility assumptions for application, database, extraction and search components before changing them.
• Decide whether snapshot restore, full rebuild or a staged combination is the preferred path.
• Require a search impact review for changes to schema, file handling, authorization and indexing workflows.
• Keep a dated record of the last successful recovery exercise and the gaps found.