# Evidence of Backup and Restore Procedure for Historian – Ignition 8.3 (Pharmaceutical Environment)

**URL:** <https://forum.inductiveautomation.com/t/evidence-of-backup-and-restore-procedure-for-historian-ignition-8-3-pharmaceutical-environment/114308>\
**Category:** Ignition\
**Tags:** ignition83\
**Created:** [March 4, 2026, 8:37am UTC](https://forum.inductiveautomation.com/t/evidence-of-backup-and-restore-procedure-for-historian-ignition-8-3-pharmaceutical-environment/114308 "2026-03-04T08:37:45Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![marco.gori](https://avatars.discourse-cdn.com/v4/letter/m/3d9bf3/32.png) [@marco.gori](https://forum.inductiveautomation.com/u/marco.gori)\
**Post date:** [March 4, 2026, 8:37am UTC](https://forum.inductiveautomation.com/t/evidence-of-backup-and-restore-procedure-for-historian-ignition-8-3-pharmaceutical-environment/114308/1 "2026-03-04T08:37:45Z")

</div>

We are preparing a software release in a **pharmaceutical environment** , therefore we have to collect clear evidence of the **backup and restore procedure for the Historian** (Built-in QuestDB) in **Ignition 8.3** as part of our validation documentation.

We would like to understand the correct procedure and best practices for the following points:

1. **Historian Backup -** What are the recommended steps to correctly back up the Tag Historian data?

2. **Historian Restore**

3. **Storage Location**

Additional context:

- The system is deployed on **Windows Server**.

- Due to regulatory constraints of the pharmaceutical environment, **Linux cannot be used**.

Thank you.

---

<div class="post-metadata">

**Author:** ![Matrix\_Engineering](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/matrix_engineering/32/19781_2.png) [@Matrix\_Engineering](https://forum.inductiveautomation.com/u/Matrix_Engineering)\
**Post date:** [March 4, 2026, 10:23am UTC](https://forum.inductiveautomation.com/t/evidence-of-backup-and-restore-procedure-for-historian-ignition-8-3-pharmaceutical-environment/114308/2 "2026-03-04T10:23:44Z")

</div>

> [@Core Historian Shows RUNNING Status but Stops Writing Data](https://forum.inductiveautomation.com/t/core-historian-shows-running-status-but-stops-writing-data/113034):
>
> Hi everyone, I wanted to share an issue I ran into while working with Ignition and the Core Historian, and also ask if anyone has seen something similar or has any recommendations. On a Gateway running Ignition 8.3.1, the Core Historian provider showed a RUNNING status with no visible errors. Tags could be configured and historized without any issues, but when trying to view the data in PowerChart, no historical values were shown and the message “No Trend Data Source available (Bad\_NotFound)” a…

Have you researched the stability of QuestDB?

Why are you not using a traditional relational DB?

---

<div class="post-metadata">

**Author:** ![marco.gori](https://avatars.discourse-cdn.com/v4/letter/m/3d9bf3/32.png) [@marco.gori](https://forum.inductiveautomation.com/u/marco.gori)\
**Post date:** [March 4, 2026, 3:07pm UTC](https://forum.inductiveautomation.com/t/evidence-of-backup-and-restore-procedure-for-historian-ignition-8-3-pharmaceutical-environment/114308/3 "2026-03-04T15:07:35Z")

</div>

Thank you for the question.

Yes, we have already evaluated alternative historian backends such as PostgreSQL with TimescaleDB specifically to handle high throughput scenarios.

However, since Ignition 8.3 introduces the embedded QuestDB-based historian, we are currently assessing whether it can be adopted in our architecture. Before making that decision, we need to understand the operational procedures around it.

In particular, because this system will be deployed in a pharmaceutical regulated environment, we must document and validate the following aspects:

• A reliable backup procedure for the historian data  
• A verified restore procedure ensuring historical data remains accessible in Ignition trends after restoration  
• Any precautions required during backup or restore operations  
• Whether the historian storage location can be configured on a dedicated drive (e.g., D:) instead of the system drive

Our goal is to determine whether the embedded historian can meet the operational and validation requirements of a regulated environment.

Any documentation or recommended procedure for QuestDB historian backup and restore in Ignition 8.3 would be very helpful.

---

<div class="post-metadata">

**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\
**Post date:** [March 4, 2026, 3:22pm UTC](https://forum.inductiveautomation.com/t/evidence-of-backup-and-restore-procedure-for-historian-ignition-8-3-pharmaceutical-environment/114308/4 "2026-03-04T15:22:43Z")

</div>

I'd definitely recommend PostgreSQL with TimescaleDB here. You can use the standard PostgreSQL backup/restore tools and it checks all your boxes. (Not sure if it's "approved" for pharmaceutical use though).

---

<div class="post-metadata">

**Author:** ![Matrix\_Engineering](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/matrix_engineering/32/19781_2.png) [@Matrix\_Engineering](https://forum.inductiveautomation.com/u/Matrix_Engineering)\
**Post date:** [March 4, 2026, 4:17pm UTC](https://forum.inductiveautomation.com/t/evidence-of-backup-and-restore-procedure-for-historian-ignition-8-3-pharmaceutical-environment/114308/5 "2026-03-04T16:17:42Z")

</div>

> [@michael.flagler](#):
>
> (Not sure if it's "approved" for pharmaceutical use though).

Ignition has proven use cases of 8.1 with, is it CFR21?

My point being, it should be easier to find proven architectures using RDB’s than Quest.

8.3 supports both, so I know what my choice would be if this project landed on my lap.

---

<div class="post-metadata">

**Author:** ![bkarabinchak.psi](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bkarabinchak.psi/32/83567_2.png) [@bkarabinchak.psi](https://forum.inductiveautomation.com/u/bkarabinchak.psi)\
**Post date:** [March 4, 2026, 4:58pm UTC](https://forum.inductiveautomation.com/t/evidence-of-backup-and-restore-procedure-for-historian-ignition-8-3-pharmaceutical-environment/114308/6 "2026-03-04T16:58:50Z")

</div>

I have personally done CFR21 projects before with RDB’s. I wholeheartedly concur. Also PSQL/Timescale rules in terms of perfomance and stability. Love it, if i I had my say I’d be using it for any project that needs a db and time series data.

---

<div class="post-metadata">

**Author:** ![marco.gori](https://avatars.discourse-cdn.com/v4/letter/m/3d9bf3/32.png) [@marco.gori](https://forum.inductiveautomation.com/u/marco.gori)\
**Post date:** [March 4, 2026, 5:13pm UTC](https://forum.inductiveautomation.com/t/evidence-of-backup-and-restore-procedure-for-historian-ignition-8-3-pharmaceutical-environment/114308/7 "2026-03-04T17:13:31Z")

</div>

Thank you for the suggestions regarding alternative architectures.

I agree that using an external relational database (e.g. PostgreSQL/Timescale or another RDBMS) is often a solid approach for historian workloads, and it is something we have already evaluated.

However, the core of my question is slightly different.

Since Ignition 8.3 introduces the embedded QuestDB-based historian, we would like to understand whether it is operationally possible to perform a backup and restore of the historian data itself, without relying on full VM snapshots.

In our case the system will run in a regulated pharmaceutical environment, and part of the validation requires documented evidence that historian data can be:

- backed up using a defined procedure

- restored successfully

- accessed again in Ignition trends after the restore

So the key point we are trying to clarify is:

Is there a supported or recommended procedure to back up and restore the embedded QuestDB historian used by Ignition 8.3 (for example at filesystem level), without relying on infrastructure-level snapshots?

---

<div class="post-metadata">

**Author:** ![Matrix\_Engineering](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/matrix_engineering/32/19781_2.png) [@Matrix\_Engineering](https://forum.inductiveautomation.com/u/Matrix_Engineering)\
**Post date:** [March 4, 2026, 5:15pm UTC](https://forum.inductiveautomation.com/t/evidence-of-backup-and-restore-procedure-for-historian-ignition-8-3-pharmaceutical-environment/114308/8 "2026-03-04T17:15:39Z")

</div>

> [@New Historian - QuestDB](https://forum.inductiveautomation.com/t/new-historian-questdb/109144/2):
>
> We do have plans to offer this, but not yet at this time. It is possible to manually perform a backup of the database, but Ignition will need to be shut down for this. We do have plans for backup / restore functionality for the full database, but not at this time. Another option would be to use ZFS snapshots on Linux. The initial offering for archiving is to allow for partitions to be restored on an external QuestDB instance. However, not to sound like a broken record, having an integrated solu…

@kurt.larson Have any of these points changed since July?
