SynetoOS speaks iSCSI. Point it at the storage you already own, and that spare capacity becomes another independent home for your Recovery Points — no new appliance, no second backup product.
Data rarely disappears in one dramatic event. It disappears because someone with stolen credentials spent a fortnight inside the network before encrypting anything, or because a migration script was pointed at the wrong datastore on a Friday afternoon. The two causes look nothing alike and they have the same defence: more than one copy, far enough apart that whatever reaches the first cannot reach the rest. The industry shorthand is 3-2-1 — three copies of your data, on two kinds of storage, one of them somewhere else — and it has outlived twenty years of technology churn.
For most of those twenty years the answer has been a backup product: an agent on every machine, a nightly window, and a separate server holding the results. It works, and millions of businesses still run on it. But it was designed when the threat was a failed disk and the clock was measured in overnight hours — and both of those assumptions have since expired.
SynetoOS starts from a different premise: protection is not a product bolted alongside the storage and the hypervisor, it is the same system. Snapshots are a property of the file system, replication moves them at block level, and recovery happens in the console your team already works in. Three consequences follow — and they land precisely where traditional backup is weakest.
So the copies are being made — on schedule, and beyond the reach of anyone who wants them gone. But look at where those Recovery Points physically sit. Perhaps the same pool as the production data they exist to protect. Perhaps the appliance a few rack units below — the one already running production for the other half of your VMs. Either way: same rack, same room, same power feed. One power event, one burst pipe above the rack, one bad afternoon in that room — and every copy you hold is on the wrong side of it.
A pair of appliances replicating both ways is a real improvement: it survives a failed pool, a dead controller, an entire chassis. But the middle number in 3-2-1 asks for two different kinds of storage, and two identical appliances are one kind — same platform, same firmware, same administrative boundary. Whatever a bad update or a stolen credential does to one, it can do to its twin. A third-party NAS or SAN breaks that symmetry, with its own controllers and its own firmware — and it is often already racked a few units away.
SynetoOS can act as an iSCSI initiator, and that single capability rewrites the arithmetic. The appliance logs in to a target on your NAS or SAN, picks up the LUN it exports as a local block device, and builds a native SyFS pool on it — the same file system, the same snapshots and the same unalterable Recovery Points as any pool on internal drives. From there it is simply a destination: point an SLA policy at it, and copies start landing on hardware that fails independently of every appliance you own.
The vault pool is a SyFS pool like any other, and that is the whole point. Replication into it is block-level and compressed, driven by the same SLA policies you already maintain — the same high-frequency RPO, the same fast RTO, restores from the same console using the procedure your team already rehearses. It sits alongside the replication you run today rather than replacing it: no second backup product, no second console, nothing new to learn. What changes is only where the Recovery Points come to rest — a different chassis, different controllers, a different power supply, on hardware that fails on its own terms instead of alongside your appliances.
The economics are just as plain. No new appliance, no rack space, no extra vendor to onboard — only the terabytes already sitting in the rack. Retention grows there instead of competing with the pools your VMs run on, which counts for most where two appliances already carry each other's Recovery Points and every gigabyte of history is charged against production capacity. Day to day the pool looks after itself: it re-imports automatically after a reboot, and targets, LUNs, pool health and session problems all surface in the console you already watch. Those pools can carry running VMs as well, where the storage network is solid enough for it.
Separate hardware is the foundation, not the finished job. An attacker who already owns your network will go looking for the Recovery Points next, so the value of a vault comes down to how few ways there are to reach it. Almost everything below is configuration rather than purchase — and the parts that happen on the SynetoOS side are console work, not a weekend of CLI.
Almost every installed base has this gap — one appliance keeping its own Recovery Points, or a pair of appliances protecting each other from the same room — and a good number of those customers already own the array that closes it. That makes iSCSI vaulting an unusually short conversation: no new hardware to quote, no incumbent product to displace, and a resilience improvement the customer can see on the dashboard the same afternoon.
Syneto backs you through it — 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.