Using multiple path.data (local + NAS/SAN per node folders) to separate hot and old data – is this supported?

Hi Team,

I am working on a Elasticsearch cluster and need clarification on a storage architecture I am planning.

My Architecture
I have the following setup:

4 Elasticsearch data nodes
Node1 → 1 TB
Node2 → 1 TB
Node3 → 1 TB
Node4 → 1 TB
A shared NAS storage of 4 TB

What I am trying to achieve

I want to separate recent (hot) data and older data:

All new data is written to local disk on each node
After 24 hours:
Older data should move to NAS storage
During search:
Recent data → from local node storage
Older data → from NAS

Detailed Approach I am considering
Each node will have:
Local data path (for active data)
NAS mount (for older data)

Example:

Node 1

path.data:

  • /local/node1
  • /nas/node1

Node 2

path.data:

  • /local/node2
  • /nas/node2

So effectively:

Each node has its own dedicated folder on NAS
Data from each node is expected to move to its respective NAS folder after some time

My Questions
Will this architecture work as expected?
i.e., local disk for recent data and NAS for older data
Does Elasticsearch support this kind of configuration?
Using multiple path.data for separating hot vs old data
Will Elasticsearch automatically move older data from local disk to NAS paths?
How does Elasticsearch decide which path.data to use?
Can it differentiate between local disk and NAS?
What issues can I face with this setup? For example:
Performance degradation due to NAS latency
File locking or consistency issues
Shard allocation imbalance
Data corruption risks
Even if separate NAS folders are used per node:
Does using NAS/NFS as part of path.data introduce risks?

My Understanding / Concern
From documentation, Elasticsearch expects storage to behave like a local disk.
Since NAS is a shared filesystem, I am unsure if:
It will behave correctly under load
Or cause issues in production

Looking for guidance

No. This is one of the many reasons why we've decided that multiple data paths was something of a misfeature and it's now deprecated. Don't use it.

We on this forum cannot answer this. Some network-attached storage does work ok, but not all.

To add to David's answer, I'd probably do something like this:

  • Use 3 nodes for hot data with local storage and Snapshots on NFS
  • Use 1 node for frozen data with local storage for Searchable Snapshots on NFS (note that this requires an enterprise license)

That way you will have hot data (let say a week of data) on local disks and older data moved to NFS. If you need to query the old data, the node 4 will then partially restore the needed files on the local disk to perform your search. It will be slower of course but it gives much more storage space at a reduced cost (less nodes needed).

My 2 cents