Ist das eine Multiuserumgebung? Eher nicht..?
Wenn es alles lokal ist und Du selbst (der Anwender) ein Restore veranlasst, ist es nicht total ok, wenn man die DBGrids (deren Connection) ausknipst?
Was würdest Du als Anwender erwarten? Das man ein Restore aufruft und das DBgrid kurz unscharf wird und dann zur Darstellung der aktuellen Daten morphed?
Ein anderes Problem wäre, ein Restore zu fahren und dabei weiterhin (wenigstens) Daten zu sammeln.
Kein RDBMS ist im "Moment" des Restore verfügbar! Das ist auch etwas, was man idR nie haben will. Das Restore betrifft die gesamte
DB. Die will ich nur aus einem Backup wiederherstellen, wenn sie sich oder jemand anders sie zerstört, korrumpiert, was weiß ich, hat.
Es gibt eine Technik, die man Partitionierung nennt. Damit werden Daten z.B. nach Timestamp (Jahre, Monate, Geschäftsjahr, Typisierung ..) geclustert, physikalisch separiet / indiziert, .. mglw in Deinem Fall nützlich und verfügbar.
Ansonsten wäre es eine Überlegung wert, dass Du per Datenmodell verschiedene "Töpfe" von Anfang an vorsiehst. Sprich separate Tabellen, für "alles was grad reinkommt", "für Export", "Backup inside", "eingehende Daten für Versuchsaufbau bei Vollmond".
Format immer identisch, vielleicht nicht mal als verschiedene Tabellen, sondern als Spalte/Klasse/Kennung einer einzigen Tabelle (siehe Partitionierung)
Das Verschieben, Export, Restore von Topf zu Topf ist dann einerseits Update auf die Kennungsspalte und im Fall import/export ein insert/delete.