01. 09. 2026
Reinhold Trocker
Log-SIEM
Query Historical Data without Restoring Everything: Using Elasticsearch Searchable Snapshots
Historical log data is valuable – until the cost of keeping every shard online starts competing with the value of the data itself. Elasticsearch searchable snapshots offer a practical middle ground for a NetEye installation: Keep an index in a snapshot repository, mount it when an investigation needs it, and query it through Elasticsearch or Kibana without performing a conventional full restore.
This article presents a controlled, manual workflow suitable for infrequently accessed NetEye Log-SIEM data: Prepare a node, create a snapshot, mount under a new name, investigate it, and delete the mounted index when the work is done.
AI transparency note: This blog entry was created with the assistance of AI and was supervised, reviewed, and corrected by a NetEye consultant.
Important: Searchable snapshots require an Elasticsearch Enterprise license. They are intended for read-only, infrequently accessed data. Validate the procedure in a non-production environment first, and follow your NetEye release’s supported service management procedure for configuration changes and restarts.
What Is a Searchable Snapshot?
A searchable snapshot is an Elasticsearch index mounted directly from a snapshot repository. Elasticsearch allocates the mounted shards to data nodes and retrieves data from the repository as required. This makes archived data searchable while avoiding a separate, traditional restore into a fully independent index.
For a NetEye investigation into older log data, a mounted index on an eligible data node with sufficient local disk capacity can be a compelling option: It preserves local disk for active data while allowing an analyst to search a specific historical index on demand.
Prerequisites and Design Checks
Before mounting an index, confirm all of the following.
- Enterprise license and compatible Elasticsearch version – Searchable snapshots must be available and licensed in the NetEye Elasticsearch deployment.
- A registered, healthy snapshot repository – The repository must be reachable by every Elasticsearch node that might host the mounted shards. Use a supported repository implementation and verify it before relying on it.
- Repository locality and cost – Keep the Elasticsearch cluster and repository in the same region/network locality where possible. Repository reads can affect latency and transfer costs.
- Read-only workflow – Mounted searchable snapshot indices are read-only. Mount under a distinct name; don’t attempt to replace a live data stream backing index.
- Lifecycle isolation – A restored name may match an existing ILM policy pattern. Clear the mounted index’s lifecycle policy unless there’s an explicit, reviewed policy for it.
Ensure that an eligible Elasticsearch data node has sufficient local disk capacity to recover the full mounted index. The default mount mode is full_copy, which stores the complete shard data locally after recovery.
Configure and Create the Snapshot
The repository configuration below is an anonymized S3-compatible example. In a real installation, configure credentials through Elasticsearch secure settings and use the repository endpoint, bucket, and TLS settings approved for the environment.
In the following, we assume that you have configured:
- A Snapshot repository named
archive-repository
in Kibana under Stack Management > Snapshot and Restore > Repositories - A snapshot policy that creates snapshots named
<daily-logs-{now/d}>that contains the indices that have to be backed up
in Kibana under Stack Management > Snapshot and Restore > Policies- optionally: enable Allow partial indices in the snapshot settings of this configuration
- optionally: enable Allow partial indices in the snapshot settings of this configuration
Run the snapshot policy, or wait for the configured schedule to run.
Confirm that the snapshot completed successfully before continuing, in Kibana under Stack Management > Snapshot and Restore > Snapshots
Mount the Snapshotted Index
Mount the index under a new name. The source index name must exactly match the index stored in the snapshot; the renamed_index must not already exist in the cluster. Unfortunately there is no way to do this in the GUI.
This anonymized request mounts the index and waits for the operation to complete:
POST /_snapshot/archive-repository/daily-logs-2026.01.30/_mount?wait_for_completion=true
{
"index": ".ds-logs-cloud.audit-acme-2026.01.29-000013",
"renamed_index": ".ds-logs-cloud.audit-acme-2026.01.29-000013-restored",
"index_settings": { "index.lifecycle.name": null }
}
Clearing index.lifecycle.name prevents the mounted index from automatically entering a lifecycle policy intended for active NetEye data. The mounted index is read-only; use it for searches, dashboards, and investigation queries – not for ingestion.
Query the Mounted Index
The index in this example is ".ds-logs-cloud.audit-acme-2026.01.29-000013-restored"
It typically only makes sense to mount data that’s not already there, so the original index ".ds-logs-cloud.audit-acme-2026.01.29-000013" is usually already cleaned up by lifecycle management (ILM). So we can assume that the original index is no longer present.
The newly mounted index is not part of the data_stream "logs-cloud.audit-acme“. If you’d prefer to do that, please consider Update data streams | Elasticsearch API documentation
In our case we assume you’d like to inspect the restored/mounted index, so you just need to use Discover and specify the index pattern in the ‘Data view’ GUI field, like ".ds-logs-cloud.audit-*-restored".
Once you’ve set the data view, you can inspect the mounted historical data. While recovery is in progress, early queries may be slower if required shard data has not yet been retrieved locally. After recovery completes, search performance is normally comparable to a regular local index.
Unmount When the Investigation Is Finished
Unmounting is simply the deletion of the mounted index. It doesn’t delete the snapshot stored in the repository.
DELETE /.ds-logs-cloud.audit-acme-2026.01.29-000013-restored
Alternatively, use the Kibana GUI: Find the index in Stack Management > Index Management > Indices (enable ‘Include hidden indices’) and delete the index using the GUI.
Verify that the mounted index no longer appears in the cluster, then retain or remove the snapshot according to the approved backup-retention policy. Never delete a snapshot until all indices mounted from it have been deleted.
Operational Takeaway
Searchable snapshots give NetEye operators a controlled way to turn archived logs back into searchable evidence without permanently consuming the same local storage as active data. The important parts aren’t just the mount request: Use a verified repository, keep lifecycle policies away from the mounted name, and remove the temporary mounted index promptly after the investigation.
References
- NetEye User Guide: Elasticsearch search results
- Elastic: Searchable snapshots
- Elastic: Mount a searchable snapshot
These Solutions are Engineered by Humans
Are you passionate about performance metrics or other modern IT challenges? Do you have the experience to drive solutions like the one above? Our customers often present us with problems that need customized solutions. In fact, we’re currently hiring for roles just like this as well as other roles here at Würth IT Italy.
Reinhold Trocker
IT professional, IT security, (ISC)2 CISSP, technical consultant
Author
Latest posts by Reinhold Trocker
15. 12. 2025
Log Management, Log-SIEM
Strange Query Results in Kibana: Understanding the Behavior of event.original and Similar Fields
20. 06. 2025
Unified Monitoring
Elastic Integration with Huge Memory Usage? Keep That Host Accessible!