elastic/elasticsearch · error · IllegalStateException
Cannot create past TSDB backing index for data stream [{}] b
Error message
Cannot create past TSDB backing index for data stream [{}] because it requires to have yet at least one time series backing index. Please rollover first. What it means
Thrown as IllegalStateException (not IllegalArgumentException) when the data stream mode is TSDB but the write index metadata is missing or its own IndexMode is not TSDB. This signals an inconsistent cluster state: the stream claims to be time series yet has no valid time series write index, so creating a past backing index is impossible. The fix the message points to is a rollover.
Source
Thrown at modules/data-streams/src/main/java/org/elasticsearch/datastreams/action/TransportPastTimeSeriesIndexCreationAction.java:540
throw new IllegalArgumentException("Cannot create past TSDB backing index for replicated data stream [" + dataStreamName + "]");
}
if (dataStream.isSystem()) {
throw new IllegalArgumentException("Cannot create past TSDB backing index for system data stream [" + dataStreamName + "]");
}
if (IndexMode.isTsdb(dataStream.getIndexMode()) == false) {
throw new IllegalArgumentException(
"Cannot create past TSDB backing index for data stream ["
+ dataStreamName
+ "] with mode ["
+ dataStream.getIndexMode()
+ "], it needs to be a time series data stream."
);
}
Index writeIndex = dataStream.getWriteIndex();
IndexMetadata writeIndexMetadata = writeIndex == null ? null : project.index(writeIndex);
if (writeIndexMetadata == null || IndexMode.isTsdb(writeIndexMetadata.getIndexMode()) == false) {
throw new IllegalStateException(
"Cannot create past TSDB backing index for data stream ["
+ dataStreamName
+ "] because it requires to have yet at least one time series backing index. Please rollover first."
);
}
}
}
View on GitHub (pinned to db6a809a66)
Solutions
- Rollover the data stream (POST <target>/_rollover or rely on auto-rollover) so a fresh TSDB write index is created
- Confirm with GET <write-index>/_settings that index.mode is time_series on the new write index
- If the write index is genuinely missing from the cluster state, restore cluster health / re-add the index before retrying
Example fix
// before: stream mode is time_series but write index is not TSDB POST my-tsds/_rollover // after: write index recreated with index.mode=time_series, then retry past-index creation
Defensive patterns
Strategy: retry
Validate before calling
// Before retrying past-index creation, ensure a TSDB write index exists:
Index writeIdx = dataStream.getWriteIndex();
IndexMetadata wim = writeIdx == null ? null : project.index(writeIdx);
if (wim == null || !IndexMode.isTsdb(wim.getIndexMode())) {
// rollover first, then retry
rollover(name);
} Try / catch
try { createPastTsdbIndex(name, ...); }
catch (IllegalStateException e) {
if (e.getMessage().contains("Please rollover first")) { rollover(name); createPastTsdbIndex(name, ...); }
else throw e;
} Prevention
- Always rollover after converting a stream to TSDB mode
- Monitor write-index mode in cluster health checks
- Gate automation on a non-null TSDB write index before invoking past-index creation
When it happens
Trigger: validateDataStream reaches the writeIndex==null || !IndexMode.isTsdb(writeIndexMetadata) branch: the write index was deleted, never created, or was created by a non-TSDB template before the stream was switched to TSDB mode. Typical right after switching mode without rolling over.
Common situations: First ingestion into a freshly converted TSDB stream before the write index has been rolled to a TSDB-backed index; mixed-version cluster where a node holds an old write index; manual metadata edits that removed the write index.
Related errors
- backing index [%s] in tsdb mode doesn't have the [%s] index
- Cannot add dynamic templates that define dimension fields on
- failed to parse value%s for setting [%s], must be lower than
- Failed to determine indexMode for data stream: {}
- Cannot create past TSDB backing index for data stream [{}] b
AI-assisted analysis of elastic/elasticsearch@db6a809a66 (2026-08-12).
Data as JSON: /api/errors/e4c43380acefc97d.
Report an issue: GitHub.