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 shows 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 complete.
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 may 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; do not 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 is 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 happen.
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 GUI way to do this.
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 usually only makes sense to mount data that is not already there, so the original index ".ds-logs-cloud.audit-acme-2026.01.29-000013" usually is already cleaned up by lifecycle management (ILM). So we assume that the original index is not present anymore.
The newly mounted index is not part of the data_stream "logs-cloud.audit-acme“, if you would like to do that, please consider Update data streams | Elasticsearch API documentation
In our case we assume you would 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 have 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 deletion of the mounted index. It does not delete the snapshot stored in the repository.
DELETE /.ds-logs-cloud.audit-acme-2026.01.29-000013-restored
Alternatively use 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 are not the mount request alone: 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
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!