# Deleting individual historian partitions?

**URL:** <https://forum.inductiveautomation.com/t/deleting-individual-historian-partitions/105941>\
**Category:** Ignition\
**Tags:** ignition81\
**Created:** [May 6, 2025, 8:07pm UTC](https://forum.inductiveautomation.com/t/deleting-individual-historian-partitions/105941 "2025-05-06T20:07:47Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Eric\_G](https://avatars.discourse-cdn.com/v4/letter/e/258eb7/32.png) [@Eric\_G](https://forum.inductiveautomation.com/u/Eric_G)\
**Post date:** [May 6, 2025, 8:07pm UTC](https://forum.inductiveautomation.com/t/deleting-individual-historian-partitions/105941/1 "2025-05-06T20:07:47Z")

</div>

I'm preparing to move the historian database to another machine. I'd like to reduce downtime by copying over as much of the historian data as possible beforehand.

My plan is to copy the database to the new system, then on the running system, drop sqlt\_data\_1\_yyyymmdd tables not from 2025, and remove rows from the sqlth\_partitions table referring to those dropped tables.

Then when we're ready to switch over, I'll again copy the (much reduced in size) running database and restore it on the new system and get it online.

Later, I'll restore the missing tables using the first copy and add their rows back into the sqlth\_partitions table.

Will this work?

---

<div class="post-metadata">

**Author:** ![hunterdg](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/hunterdg/32/67774_2.png) [@hunterdg](https://forum.inductiveautomation.com/u/hunterdg)\
**Post date:** [May 7, 2025, 5:50am UTC](https://forum.inductiveautomation.com/t/deleting-individual-historian-partitions/105941/2 "2025-05-07T05:50:18Z")

</div>

I feel like purging the partition pointers isn’t necessary. Otherwise - seems reasonable (but unsupported I imagine) - test it first of course

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [May 7, 2025, 10:55am UTC](https://forum.inductiveautomation.com/t/deleting-individual-historian-partitions/105941/3 "2025-05-07T10:55:59Z")

</div>

This topic might help:

> [@Tag History Migration Best Practices? Upgrading to new servers!](https://forum.inductiveautomation.com/t/tag-history-migration-best-practices-upgrading-to-new-servers/75766/2):
>
> If you are allowed downtime, it is as simple and making the new database connect just like the old database, using the same database connection (just update the driver ahead of time). MariaDB slots in as a replacement for MySQL quite nicely. Switch to DNS names in the connection URL before old shutdown if you are going to change IP addresses--make that DNS name point at the new DB before new gateway startup/restore. So: Switching to DNS name for DB connection and put in mutually compatible…