File Types

Overview

Timebase creates a defined set of file types as it stores data, maintains state, and protects against corruption. Knowing what each file does helps you back up the right files, understand what you see on disk, and recover correctly after a failure.

Files are written into two root locations by default:

Data and state: C:\ProgramData\Flow Software\Timebase\Historian\Data\<DatasetName>\
Logs and settings: C:\ProgramData\Flow Software\Timebase\Historian\

These paths can be changed in settings.config.

File type reference

Data files

These are the files that contain your historical time-series data. They are the primary files to include in any backup.

File / pattern	What it contains	Backup?
`YYYY-MM-DD HH.N.data`	One hour of numeric and boolean tag values. Created every hour. The `N` is a partition index (0, 1, 2 …) — each partition holds up to 20,000 tags. A dataset with 60,000 tags produces three `.data` files per hour.	Yes
`YYYY-MM-DD HH.0000.object`	One hour of object values — strings, JSON blobs, arrays. Created every hour alongside the `.data` files when string or object tags are present.	Yes
`YYYY-MM-DD HH.N.last`	Last known value for every tag in the corresponding `.data` block. Updated every time new data is written. Used to answer "latest value" queries instantly without scanning the full block. If this file is missing or corrupt, the Historian rebuilds it automatically from the `.data` file — no data is lost, but startup is slower.	Recommended
`YYYY-MM-DD HH.N.late`	Late (out-of-order) data waiting to be merged into the corresponding `.data` block. Created when the Collector sends data with a timestamp earlier than the block's most recent point — this happens during store-and-forward replay. The file is deleted automatically once the merge is complete. If you see persistent `.late` files, a merge is in progress or was interrupted.	No (transient)
`YYYY-MM-DD HH.0000.object.bak`	Backup copy of the previous verified write of the `.object` file. Created automatically by `File.Replace` — always one confirmed-good save behind. If the primary `.object` file is corrupt (fails to deserialise), the Historian falls back to this file, restores the primary from it, and logs a warning. Safe to delete if disk space is a concern, but keeping it improves resilience against unexpected crashes during a write.	Optional — kept for resilience

State and configuration files

These files hold tag metadata and dataset/tag state. They are required alongside the data files for a complete and usable backup.

File	What it contains	Backup?
`tag.config`	Critical. Maps each tag's internal ID to its name, description, unit of measure, data type, and fields (metadata). Without this file, the Historian cannot associate tag names with the binary data in `.data` and `.object` files — data becomes unreadable. Must always be backed up with your data files.	Yes — required
`dataset.config`	Dataset-level configuration — purge age, purge size, and other dataset properties. Separate from `tag.config`. Required to restore the dataset with the same settings.	Yes
`tag.state`	Current write state for each tag — used during dataset initialisation to resume correctly after shutdown.	Recommended
`dataset.state`	Current state of the dataset as a whole (Running, Stopping, Stopped, etc.). Read at startup to determine whether any hourly block recovery is needed after an uncontrolled shutdown.	Recommended
`settings.config`	Historian process configuration — Kestrel network endpoints, logging levels, custom data/log paths, and authentication settings. Stored at `C:\ProgramData\Flow Software\Timebase\Historian\Settings\`. Back this up so you can restore the Historian to the same network and auth configuration.	Yes

Log files

Extension	What it contains	Backup?
`.txt`	Plain-text log files. Not needed to restore data, but essential for diagnosing failures. Default location: `C:\ProgramData\Flow Software\Timebase\Historian\Logs\`	No (for recovery) — Yes (for diagnostics)

Transient files — safe to ignore

These files are created and deleted automatically during normal operation. You should not see them when the Historian is idle. If they persist after a clean shutdown, they are safe to delete.

File pattern	Purpose
`*.data.temp`	Intermediate write buffer for `.data` files. Written first, then atomically promoted to the final file. Prevents partial writes from corrupting the primary file.
`*.object.temp`	Same as `.data.temp`, for `.object` files.
`*.last.temp`	Intermediate write for `.last` (last-value cache) files.
`*.late.temp`	Intermediate write for `.late` (late data buffer) files.
`dataset.state.temp`	Intermediate write for `dataset.state`.
`dataset.config.temp`	Intermediate write for `dataset.config`.
`tag.config.temp`	Intermediate write for `tag.config`.
`tag.state.temp`	Intermediate write for `tag.state`.
`tag.last.temp`	Intermediate write for `tag.last`.

Troubleshooting

Symptom	Likely cause	What to do
Data files are present but the Historian shows no tags or data after a restore	The `tag.config` file was not included in the backup	`tag.config` maps tag names to the binary data in `.data` and `.object` files. Without it, data cannot be decoded. Always back it up alongside the data files. If it is lost, the data in those files cannot be recovered
The Historian logs "Failed to deserialize" for an `.object` file on startup	The `.object` file was partially written (e.g. due to a crash mid-write)	The Historian automatically falls back to the `.object.bak` file if one exists, restores the primary from it, and continues. If both the primary and `.bak` are corrupt, restore from your external backup
Persistent `.late` files remain after the Historian has been running for a while	A `.late` file merge was interrupted (e.g. the Historian was stopped during a backfill), or the Historian is still actively merging a large backfill	The Historian merges `.late` files automatically during each write cycle. Allow it to run. If files persist after 30+ minutes with no new data arriving, check the Historian logs for merge errors
`.temp` files remain on disk after the Historian is stopped	The Historian was shut down unexpectedly (crash, power loss) while writing	These are safe to delete when the Historian is not running. The Historian re-creates them as needed on the next write
The Historian startup is slow after restoring from backup	`.last` files were not included in the backup; the Historian is rebuilding them by scanning each `.data` file	This is automatic — no action needed. Include `.last` files in future backups to avoid the rebuild delay
Disk space is larger than expected from the number of tags logged	Old hourly `.data` and `.object` files are accumulating, or `.bak` files are doubling the storage for `.object` files	Check the dataset purge settings (purge age/size) via the Historian browser or REST API. Old hourly files can be archived or deleted without affecting ongoing logging. `.bak` files are roughly the same size as their primary `.object` file