> For the complete documentation index, see [llms.txt](https://docs.videc.de/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.videc.de/acron-9.3/en/ac_admin/anlagenuebersicht/anlage/dienste_und_anwendungen/mirror.md). # Mirror Some plant installations require a redundancy concept for their control and data retention as a security measure. This is the only way to ensure that operations can be maintained without delay following a total failure of a system component on another system of the same type. The ACRON Mirror software product was developed in order to meet these requirements. ACRON Mirror enables the ACRON data on one computer to be kept identical to the ACRON data held on another. This makes it possible to implement both a backup solution and full fail-safe redundancy. This means operations can be immediately continued on another computer if a database server fails. As soon as the failed computer is restored to operation, it updates its data from the other computer. Synchronization takes place by checking the respective files for modifications and synchronizing them if necessary. By default, the process values are synchronized at data record level, and the configuration data at file level. The following are some scenarios for ACRON Mirror with recommended or required settings. As ACRON Mirror identifies the plant to be mirrored via the TCP/IP address and the plant’s database server port, the term “plant” is used in the following instead of computer. *Scenario 1* - **Plant ABC** on **server 1** as backup for **plant DEF** on **server 2** Example procedure for configuring a new backup plant: * In ACRON Admin, a new empty plant ABC is created on server 1. * The mirror to the plant DEF being mirrored is configured on this plant: * To do this, enter the IP address of server 2 in the TCP/IP address input field * and the port number of the database server of plant DEF in the Port input field. * Test the connection. * If the connection is successful, the mirror then be started. * After the mirror has synchronized, the backup plant (plant ABC) has the same status as the source plant (plant DEF). Note No provider may run on **plant ABC**, and no configuration changes can be made on it. Background: The data recorded here, or any configuration changes made, would be overwritten during the synchronization update at the latest. To synchronize process data from the mirror on **plant ABC**, choose Suppress record-by-record synchronization. Background: Complex data synchronization of possibly competing data at value level is not necessary here, so the synchronization is much more efficient. ![](/files/ZV3UBu4I4lo57ejD9olv) Variant: Server 1 as backup for plant EFG on server 2 and plant KLM on server 3 ![](/files/8DdIiGGg3kb5up3toY2G) *Scenario 2* - **Plant ABC** on **server 1** and **plant DEF** on **server 2** as redundancy plants (full fail-safe redundancy) * The database server, database engine and provider must run on both plants. * The providers are connected to the PLS according to its configuration (e.g. primary and secondary PLS). * The mirror to **plant DEF** is configured on **plant ABC**: * To do this, enter the IP address of **server 2** in the TCP/IP address input field * and the port number of the database server of **plant DEF** in the Port input field. * The mirror to **plant ABC** is configured on **plant DEF**: * To do this, enter the IP address of **server 1** in the TCP/IP address input field * and the port number of the database server of **plant ABC** in the Port input field. * Test the connections on both plants, and if the connection is successful start the mirror. * Synchronizing the two ACRON mirrors ensures that the configuration and data sets on both plants are kept identical. If **plant ABC** fails, for example, you can continue working with **plant DEF**. When **plant ABC** resumes, while synchronizing the mirror of **plant ABC** retrieves all newer data from **plant DEF**, thereby updating **plant ABC**. Note The Suppress record-by-record synchronization option must not be used here, as it can lead to data loss. For the 'primary' plant, the Time synchronization and Prioritize this computer’s data options should be enabled. ![](/files/oLJCviqR8AGl4nALx9pk) *Scenario 3* - Plants in different time zones The following rules apply to this scenario: * Provider process data recording and manual data recording (manual values, comments, etc.) may only run on one plant. So full redundancy as described in scenario 2 is not feasible here. * For process data synchronization, the Suppress record-by-record synchronization option **must** be selected. In this, the data time stamps are not converted into the respective time zone, but are applied directly. * The Time synchronization option must not be enabled. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.videc.de/acron-9.3/en/ac_admin/anlagenuebersicht/anlage/dienste_und_anwendungen/mirror.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.