Replication is a setting on the protection policy you already run — not a second product to buy and learn. Two nodes in one room, a site far away, or both: the same policy, the same console, and a failover you can undo.
Almost every company that runs its own servers has something it calls a disaster recovery plan. Copies are being made, a document exists, and somebody could probably find it. The uncomfortable questions are the two nobody asks: which failures do those copies actually survive, and has anyone ever tried.
Two very different bad days hide behind the word disaster. One is losing a node — a controller, a chassis, a storage pool. The other is losing the room: fire, flood, a power event, a building nobody is allowed to enter. They are not equally likely, and the node failure is the one most businesses will actually meet — so a plan written entirely around the rare catastrophe often leaves the common one uncovered.
Long before either arrives, though, a DR setup usually dies quietly on its own — and not from bad luck. It eats the network: replication that saturates the upload while people are working gets switched off by lunchtime, and nobody makes a note of it. Nobody notices when it breaks: replication that failed three weeks ago looks exactly like replication that ran last night, right up to the morning you need it. The copies cannot be trusted: a recovery point is only worth having if it was consistent when taken, is intact when you reach for it, and sits beyond the reach of whatever broke production.
And a recovery procedure that has never been executed is not a plan, it is a hypothesis — traditionally because testing one cost money, downtime, or both. None of these failures is inevitable. Each of them has an answer.
NIS2 moves business continuity and tested recovery from good practice to legal obligation, with incident-reporting deadlines measured in hours rather than weeks. For organisations in scope, the untested binder stops being a quiet risk and becomes a compliance exposure — and the evidence that recovery works has to exist before anybody asks for it.
SynetoOS is a universal, resilient data management platform with an HCI architecture: hyperconverged, meaning one system runs your virtual machines, holds the data underneath them, and protects that data — rather than three products stitched together in the hope that they agree. Which is why disaster recovery here is not a second purchase, a second console and another set of schedules to maintain: because the platform running a workload is also the platform storing and protecting it, replication is a setting on the protection policy you already maintain.
Your appliance did not arrive empty. Three protection policies are already defined and running — Silver, Gold and Platinum — each a complete ladder from frequent short-term recovery points up to monthly ones kept for a year. They are already protecting your virtual machines. The only thing they do not have is a replication target. Add one, and the policy you already rely on becomes your disaster recovery plan.
Retention is decided per destination — a short local history where you want data back in seconds, a long remote history where capacity is cheaper. One policy, two retentions. Keeping months of history stays affordable because recovery points are forever incremental and unlimited in number, and compression — measured at 1.5× on average across our installed base — reduces both what sits on disk and what crosses the link.
Two failures deserve two answers. The first is the one people rarely think of as disaster recovery at all: two standalone nodes in the same datacentre, both running production workloads, replicating to each other. Neither is a standby — both earn their keep every day, so there is no idle hardware to justify to whoever signs the invoice. If one is lost, its virtual machines are brought up on the other and the business carries on at LAN speed. The second is the conventional answer, and the only thing that survives losing the room: a target somewhere else — a second office, a colocation rack, or your integrator's datacentre.
The two tiers are not configured identically. Replication between nodes on your own network can run unencrypted, which buys a faster transfer rate; anything leaving your building runs encrypted. Every destination is configured on its own merits — rather than one blunt setting applied everywhere.
Six things decide whether a DR setup survives contact with daily operations. Replication is configured per destination and reports on itself, so it neither degrades the working day nor stops without saying so — and the copies it leaves behind are worth having at the moment you reach for them.
Crash-consistent, application-consistent — with VSS hooks on Windows, so applications are quiesced properly rather than merely paused — and memory-consistent, which captures RAM alongside the disks.
Replicate at all times, cap it to a set rate during nominated hours, or block it outright while people are working. Set per destination, genuinely enforced, and an interrupted transfer resumes where it stopped.
A destination that goes offline, or a remote pool filling up, raises an alert instead of failing silently — while there is still time to do something about it.
Once written, a recovery point cannot be altered after the fact — by anyone, with any level of access.
Pins what must survive regardless of policy. While the hold stands it cannot be deleted or aged out — administrators included.
Identity is re-verified throughout the session, not only at the login prompt. A session somebody else has taken over cannot quietly start destroying history.
Pick the virtual machine and start its failover from the latest recovery point. Nothing is committed yet.
It registers on the host you choose, with its networks remapped to the ones that make sense there, and powers on.
Confirm the workload is what you expect — optionally on an isolated segment, where nothing else can reach it.
Make it permanent, or roll it back as though it never happened.
Failover is per virtual machine and deliberately two decisions, not one: you initiate it, then — separately, when you are ready — you confirm or revert it. It is built that way because the person doing this is having the worst morning of their quarter, and the first click must not be irreversible. The same procedure covers both tiers, so the local failover your team is actually likely to perform is also a rehearsal for the remote one.
That reversibility is also what makes testing affordable. Network attachments are chosen at failover time, so a machine can come up on an isolated segment, be inspected, and the failover reverted — and zero-copy cloning means it costs no storage either. A rehearsal that is neither expensive nor frightening is one that actually happens, and each one leaves a record behind it, so what an auditor asks for under NIS2 is a report you already have.
The two tiers are the same mechanism. Same policies, same replication, same failover procedure. Adding the second tier means adding a destination, not adopting a second product — so beginning with local DR and extending off-site later costs you no redesign and no rework. You are not committing to an architecture today; you are adding a destination to a policy that is already running.
None of it depends on running Syneto's own hypervisor, either. SynetoOS protects VMware environments — standalone ESXi hosts or vCenter — as readily as it protects Hyperion. You are not being asked to migrate your virtualisation platform first.
Two conversations open up here. The first costs the customer almost nothing: a second node they may already own, cross-replicating with the first, both in production — node-level resilience with no new site and no DR licence to quote. The second is your own datacentre as their off-site target, which turns a one-off sale into a recurring service on infrastructure you already run.
Syneto backs you through both — hands-on help with proof-of-concepts, our customer success team alongside you during the assessment, and post-sales support from native speakers of your language.
Join 5,000+ European companies that trust Syneto.
© 2026 Syneto SpA. All rights reserved. "Syneto", the Syneto logo, "SynetoOS", "Syneto CENTRAL", "Hyperion", "HYPER Core", "HYPER Edge", and "HYPER Echo" are trademarks of Syneto SpA. All other trademarks are the property of their respective owners.