Sometimes the data you need to get into a historian lives in a file rather than a live feed: a datalogger export, a spreadsheet kept during an outage, or records rescued from a device that was offline. Backfilling from a CSV file is the practical way to load that history into the archive so it sits alongside everything else. Done carelessly it introduces wrong timestamps, mislabeled quality, and duplicate rows; done properly it recovers data that would otherwise be lost. This page walks through the procedure: mapping the columns, handling timezones and duplicates, tagging imported values with an appropriate quality, and verifying the result against the archive's compression and acceptance rules.
Backfilling a historian from CSV in one line: To backfill a historian from a CSV file, map the file's timestamp, value, and quality columns to the target tags, resolve the timezone so timestamps land at the correct absolute time, handle duplicate rows before import, and tag the imported points with a quality that marks them as substituted or manually entered. Then verify the loaded data against the archive's backfill window and compression settings, checking that it landed in the right place and was not rejected or distorted.
The situation that calls for a CSV backfill is recognizable: there is a gap in the historian, and the data that belongs in that gap exists somewhere outside the archive. Perhaps a collector was down during an outage and a local datalogger kept recording, perhaps an instrument was on a standalone logger that was only read periodically, or perhaps someone kept a manual spreadsheet while the automation was offline. In every case the raw information survives in a file, and the task is to move it into the historian so that queries, trends, and reports over that period are complete rather than showing a hole.
Before importing anything, it is worth confirming that a file import is the right mechanism rather than a live recovery. If the gap is due to a collector outage and the collector itself buffered the data, the cleaner path is to let the collector drain its buffer, because that data carries proper timestamps and quality natively. File backfill is for the cases where no buffered recovery is possible: the data only ever existed in the file, or the buffering was lost, or the source was never connected to the historian at all. Establishing that up front avoids importing a file that duplicates data the collector is about to deliver anyway.
It also helps to understand the file itself before touching the historian. Open the CSV and confirm what each column contains, what format the timestamps use, whether there is a header row, what the sampling interval is, whether there are gaps or blank cells, and whether any quality or status information is present. Many import problems are really file-understanding problems: a timestamp column that is actually local time assumed to be something else, a value column with units that differ from the tag, or blank rows that will import as bad data. A few minutes reading the file prevents a bad import that then has to be found and undone.
The heart of the import is mapping: telling the import process which column is the timestamp, which is the value, which is the quality if present, and which historian tag each value belongs to. If the file holds several tags in separate columns or interleaved rows, each has to be routed to its correct destination tag, and the value column has to be interpreted in the right engineering units so a reading is not stored as a raw or differently scaled number. This mapping is where most of the care goes, because a value placed on the wrong tag or read in the wrong units corrupts the archive in a way that is hard to spot later. Getting the mapping exactly right for a small sample before running the whole file is a sensible discipline.
Timezone handling is the single most common source of silent error in file backfill. A CSV timestamp is just text until you decide what timezone it represents, and if the file was written in local time but imported as if it were the archive's timezone, or vice versa, every value lands at the wrong absolute moment, offset by hours. The fix is to determine explicitly what timezone the file's timestamps are in, account for any daylight-saving transitions within the data, and convert to the absolute time the historian expects, so an event recorded at a given local time appears at that same real moment in the archive. Never assume the file and the historian share a timezone; confirm it.
Duplicate rows need handling before or during import, because they cause exactly the timestamp collisions that historians deal with in inconsistent ways. A file may contain repeated rows from a logger that recorded twice, or overlapping exports that share some rows, and if two rows carry the same tag and timestamp with different values, the archive's response, overwrite, reject, or keep-both, is not something you want to leave to chance. Deduplicate the file first, deciding deliberately which value wins when a timestamp repeats, so the import presents clean, unambiguous data rather than relying on the historian's collision policy to sort out a mess you could have resolved in the file.
Imported historical data should not masquerade as normal, live-collected measurements, so it is good practice to tag the imported points with a quality that marks them as substituted, manually entered, or otherwise not from the normal collection path. This quality flag is honest record-keeping: anyone later reading that period can see that these values came from a file backfill rather than the live system, which matters for trust and for any analysis that should weight or exclude manually loaded data. Preserving any quality information the source file carried, and adding a substituted-value marker for the import itself, keeps the archive's provenance clear rather than blurring imported data into the live record.
Verification after the import is essential, because a file backfill interacts with the same archive rules as any other write. Confirm that the imported timestamps actually landed in their intended positions and were not rejected or shifted by the backfill acceptance window, which is a real risk if the data is old and the window is narrow. Check that the values reconstruct sensibly against the tag's compression settings, so the import did not produce a distorted trend, and spot-check a few points against the original file to be sure the mapping, units, and timezone all came through correctly. Treating the import as done only after this verification is what separates a reliable backfill from one that quietly loaded wrong or missing data.
In a SCADA and cloud monitoring context, file backfill is often how data from the edges of a system, standalone loggers, temporarily disconnected devices, or manual records, is reconciled into the central archive so that the historian is genuinely complete. A platform such as Merobix supports importing such historical data with explicit column mapping, timezone handling, and quality tagging, and it applies its acceptance-window and compression rules to imported data just as to live data, so an operator can see that a manual load succeeded and where. That combination, a clear import path plus verification against the same rules the live data obeys, is what lets a team recover lost history from a file with confidence that the result is accurate and clearly marked for what it is.
Yes. Tag imported points with a quality that marks them as substituted or manually entered so anyone later reading that period can see the values came from a file backfill rather than the live system. This honest provenance matters for trust and for any analysis that should weight or exclude manually loaded data. Preserve any quality the source file carried and add a substituted-value marker for the import itself so the archive's record stays clear.
Timezone mishandling is the most common silent error. A CSV timestamp is just text until you decide what timezone it represents, and if the file is in local time but imported as the archive's timezone, or vice versa, every value lands at the wrong absolute moment, offset by hours. Determine the file's timezone explicitly, account for daylight-saving transitions, and convert to the absolute time the historian expects rather than assuming the two share a timezone.
Confirm the imported timestamps landed in their intended positions and were not rejected or shifted by the backfill acceptance window, which is a real risk for older data with a narrow window. Check the values reconstruct sensibly against the tag's compression so the trend is not distorted, and spot-check several points against the original file to confirm the mapping, units, and timezone all came through. The import is only done once this verification passes.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.