InTouch with Redundant Historian?

Update!

I must admit that after posting my message I started to think that I, in my comments assumed that the (new) feature in InTouch to send data to a Historian worked in the same way as when logging data from Application Server (using similar feature).

So I decided to test to verify, and came to the conclusion that there are some features not fully available in InTouch yet.

When setting up two historians in a Pair you indeed get failover on a client level, but on a data provider level it seems to be differences.

In Application Server, adding objects with History enabled will create the attribute configuration (tag) in both Historians.

But when I try this in InTouch it will only create the tag in the primary server, leaving the redundant partner unaware of the new tag.

And the result of this is that in a scenario where the primary historian server is offline, no data from InTouch is ever logged to the backup, but when it comes online the Store and Forward feature will backfill the missing data on the primary historian.

On a client level, ie. in the Trend Client it will stay 'connected' though and you will be able to find and select only the tags available on the backup historian.

In a scenario of Application Server as the data provider it behaves as you might expect, If the primary server is offline it will continue to feed the backup historian server with data.
And when the primary server is online again, store forward will fill in the missing data, thus enabling redundance. (at least on this level, the subject of full redundancy is quite vast and can be built for many scenarios).

Since configuring InTouch to Enable logging to historian, witch is a quite new feature, it will be able to push data to the configured historian, and even the alarms and events generated with Store and Forward capability, witch is a huge advantage compared to the previous possibility, to manually configure historian to retrieve data from InTouch (view.exe) using a Suitelink connection. there are many tools to simplify this step, but in its core Historian uses InTouch as a datasource similar to any Device Integration Driver.
And if you want to achieve Store and Forward in this scenario, you have to set up an IDAS component on the InTouch Node.

The limitations are also related to the logging of Alarms, that from InTouch it will not support redundancy, yet.

So to re-conclude, If you want to achieve redundancy of Historian data, you might need to revert to the solution where you have two historians retrieving data from the same datasource, in this case, InTouch. (as already suggested by RAINER CARLTON DSOUZA )

Or look in to the Historian feature of Replication, depending on what is the need and possibility in your scenario.

Update!

I must admit that after posting my message I started to think that I, in my comments assumed that the (new) feature in InTouch to send data to a Historian worked in the same way as when logging data from Application Server (using similar feature).

So I decided to test to verify, and came to the conclusion that there are some features not fully available in InTouch yet.

When setting up two historians in a Pair you indeed get failover on a client level, but on a data provider level it seems to be differences.

In Application Server, adding objects with History enabled will create the attribute configuration (tag) in both Historians.

But when I try this in InTouch it will only create the tag in the primary server, leaving the redundant partner unaware of the new tag.

And the result of this is that in a scenario where the primary historian server is offline, no data from InTouch is ever logged to the backup, but when it comes online the Store and Forward feature will backfill the missing data on the primary historian.

On a client level, ie. in the Trend Client it will stay 'connected' though and you will be able to find and select only the tags available on the backup historian.

In a scenario of Application Server as the data provider it behaves as you might expect, If the primary server is offline it will continue to feed the backup historian server with data.
And when the primary server is online again, store forward will fill in the missing data, thus enabling redundance. (at least on this level, the subject of full redundancy is quite vast and can be built for many scenarios).

Since configuring InTouch to Enable logging to historian, witch is a quite new feature, it will be able to push data to the configured historian, and even the alarms and events generated with Store and Forward capability, witch is a huge advantage compared to the previous possibility, to manually configure historian to retrieve data from InTouch (view.exe) using a Suitelink connection. there are many tools to simplify this step, but in its core Historian uses InTouch as a datasource similar to any Device Integration Driver.
And if you want to achieve Store and Forward in this scenario, you have to set up an IDAS component on the InTouch Node.

The limitations are also related to the logging of Alarms, that from InTouch it will not support redundancy, yet.

So to re-conclude, If you want to achieve redundancy of Historian data, you might need to revert to the solution where you have two historians retrieving data from the same datasource, in this case, InTouch. (as already suggested by RAINER CARLTON DSOUZA )

Or look in to the Historian feature of Replication, depending on what is the need and possibility in your scenario.

Thanks Richard and Rainer for quick response.