30. 12. 2025
Automation, Development, Log Management, Log-SIEM, NetEye
In this blog post, I’d like to share insights into the implementation of a NetEye disaster recovery (DR) environment that we recently successfully deployed for a customer.
As many of you probably know, integrating IT applications into a disaster recovery environment is often not straightforward. Challenges can arise from various factors such as complex database installations, replication mechanisms, or applications running on physical hardware.
The same applies to a NetEye implementation. Depending on how the NetEye environment was originally designed and implemented, there are different approaches for integrating it into an existing disaster recovery strategy.
Initial Situation and Requirements
In this particular use case, the NetEye environment consisted of:
- Two physical servers
- One virtual voting node
Due to the high hardware requirements, the customer intentionally decided to run the environment on dedicated physical servers.
In addition, the customer already had existing business continuity infrastructure consisting of two geographically separated datacenters. All server and storage systems were configured in a highly available setup across both locations. This means that if one datacenter fails, the second one can fully take over operations.
This existing infrastructure formed the basis for integrating the NetEye environment into the DR concept.
Chosen Disaster Recovery Solution
After several technical evaluations and successful testing phases, we implemented the following solution.
Virtual Voting Node
Since the virtual infrastructure was already replicated to the DR site, the implementation of the virtual NetEye voting node was essentially already in place and only needed to be integrated into the overall concept.
Physical NetEye Servers
For the physical NetEye nodes, we chose the following architecture:
- Three identical physical servers were purchased
- The systems did not contain local disks and were fully configured for “Boot from SAN”
- One server was installed in each datacenter as well as at the DR location, all configured identically
- All systems use the same network and SAN configuration
As a result, each server is directly connected to the SAN infrastructure at its respective location.
The operating system and the NetEye application were initially installed and configured on the two production servers at the primary site.
Storage Replication
Since the storage infrastructure already included an existing replication solution, the storage volumes of one of the productive NetEye nodes were continuously replicated to the SAN at the DR location.
This setup allows one physical node together with the virtual voting node to be started at the DR site in case of a disaster recovery scenario.
Because both NetEye nodes contain the same replicated data, the customer decided that running a single NetEye node in the DR environment would be sufficient during an emergency situation.
DR Failover Scenario
In the event of a disaster, a physical NetEye node can be started at the DR location using the same IP address and network configuration as the original production server at the primary site.
This approach enables the NetEye environment to continue operating with minimal changes and short recovery times.
Conclusion
This implementation demonstrates that even complex physical NetEye environments can be successfully integrated into existing disaster recovery concepts – especially when a well-designed business continuity and storage replication strategy is already in place.
Key success factors for such an implementation include:
- Careful infrastructure planning
- Identical hardware and network configurations
- Reliable storage replication
- Realistic testing scenarios before going live
With this approach, we successfully implemented a robust yet relatively straightforward disaster recovery solution for the NetEye environment.
These Solutions are Engineered by Humans
Did you find this article interesting? Does it match your skill set? Our customers often present us with problems that need customized solutions. In fact, we’re currently hiring for roles just like this and others here at Würth IT Italy.
Tobias Goller
NetEye Solution Architect at Würth IT Italy
I started my professional career as a system administrator.
Over the years, my area of responsibility changed from administrative work to the architectural planning of systems.
During my activities at Würth IT Italy, the focus of my area of responsibility changed to the installation and consulting of the IT system management solution WÜRTHPHOENIX NetEye.
In the meantime, I take care of the implementation and planning of customer projects in the area of our unified monitoring solution.
Author
Latest posts by Tobias Goller
16. 02. 2026
Unified Monitoring
OpenShift Monitoring in NetEye
13. 10. 2025
Log-SIEM, Unified Monitoring
Elastic Defend: Experiences
18. 07. 2025
Automation, Cloud
Running SOS Berlin JobScheduler in Containers: A Step Toward Cloud-Native Scheduling
16. 04. 2025
NetEye, Unified Monitoring
Application Performance Monitoring in NetEye with Elastic APM and OpenTelemetry