Two problems that look alike but aren’t: keeping a service online through a hardware fault, and recovering data after it’s been encrypted or deleted. This deployment solved both deliberately, with different tools.
A Malta-based organisation running business-critical workloads approached Sirap with a requirement that’s easy to state and easy to get wrong: it could not afford extended downtime, and it could not afford to lose data to ransomware. Those sound like the same problem. They are not, and the most common mistake we see is a business buying a resilient storage system and assuming it has solved both. As Malta’s only Synology Platinum Partner, our job here was as much about drawing that distinction clearly as it was about specifying hardware.
The challenge
The client’s services could not tolerate extended outages. A failed storage controller or power supply had the potential to halt operations for as long as it took to source and configure a replacement. At the same time, their existing backup lived on the same site as the primary data, which meant a fire, a theft, or, most likely of all, a ransomware event could take out both copies in a single incident. They needed two things addressed independently: continuous availability at the hardware level, and a backup that an attacker who had fully compromised the network still could not reach.
Why availability and backup are different problems
A high-availability cluster keeps a service running when hardware fails. It does this by maintaining a second server that mirrors the first in near real time, ready to take over. That is genuinely useful – but it protects against hardware faults, not against the data itself going bad.
The catch is in the word “mirror.” If a file is encrypted by ransomware, or a folder is deleted in error, that change is faithfully replicated to the standby server within seconds. The cluster does exactly what it was designed to do, and now both copies are equally unusable. High availability shortens the window where a machine is offline; it does nothing for the situation after data has been corrupted. That is what a backup is for, and why this deployment needed both layers rather than one.
The solution: the high-availability layer
For continuous availability we deployed a Synology SA3200D, a 12-bay dual-controller RackStation built specifically for this role. Its two controllers run active-passive: one handles all requests while the other holds an exact, continuously updated replica of the data and system state. If the active controller becomes unavailable, the cluster fails over to the standby automatically, typically within about a minute. Redundant, hot-swappable power supplies and fans remove the single points of failure that most often take a single-controller unit offline.
The detail that decides whether HA actually works: the heartbeat
Synology High Availability depends on a dedicated “heartbeat” link between the two controllers, used to detect failure and keep the replica current. Synology’s own guidance – and our standard practice – is that this link should be a direct cable between the two servers rather than a path through a switch, because a switch adds a component whose failure can be misread as a server failure. It should also run at the same speed as the production network or faster: on a 10GbE service, the heartbeat belongs on a 10GbE interface, not a spare 1GbE port. Getting this wrong is the difference between a cluster that fails over cleanly and one that behaves unpredictably under load.
Designing against split-brain
The failure mode every HA design has to plan for is “split-brain” – both controllers simultaneously deciding they are the active server, then writing inconsistent data. It happens when the controllers lose sight of each other but both stay alive. We mitigate it using a quorum reference on the network: if the active controller can no longer reach that reference but the passive one can, the cluster has an objective basis for deciding which node should take over, rather than both seizing the role. It’s an unglamorous part of the design that matters enormously the one time it’s needed.
Honest limits worth knowing
HA is not magic, and we set expectations accordingly. Failover takes a short interval, during which active sessions reconnect rather than carry on seamlessly – it minimises downtime, it doesn’t abolish it. Drive positions are fixed once the cluster is built, and a Synology HA cluster has defined ceilings on total volumes and capacity. None of these were constraints for this client, but they’re the kind of thing worth knowing before deployment rather than after.
The solution: the backup layer
For the part HA cannot do, we used Synology Hyper Backup to replicate data to a separate XS+ RackStation at a second location. Two design choices made this a genuine safety net rather than a second copy waiting to be encrypted alongside the first.
Air-gapping, properly understood
The backup target is kept isolated from the production network so that a compromise of the primary site cannot route to it and encrypt or delete the copy. “Air gap” gets used loosely; here it means the target is not reachable from the production environment in normal operation, closing the path ransomware would otherwise take to destroy both copies at once.
Immutable snapshots: the layer that survives a stolen admin password
Isolation reduces the risk; immutability removes a whole class of it. On supported Synology models running DSM 7.2 and Btrfs, snapshots can be made immutable (WriteOnce / WORM) – locked for a defined retention period during which they cannot be altered or deleted by anyone, including an administrator account. This matters because modern ransomware specifically hunts for and deletes snapshots and backups before encrypting, frequently using stolen admin credentials. A snapshot that even a compromised admin cannot remove for, say, fourteen days is one you can still restore from after an attack. It’s worth distinguishing this from simple snapshot “locking,” which only stops the retention policy from auto-pruning; true immutability is the control that defends against a malicious actor holding full access.
A backup is only real if it restores
Hyper Backup’s deduplication keeps the offsite footprint small and its multi-versioning enables point-in-time restores, but the feature that earns its place is integrity detection – verifying that the backup is consistent and restorable rather than assuming it. An untested backup is a hope, not a plan, so we validate restores as part of handover. The recovery path is known to work before it’s ever needed in anger.
Why this combination, in one view
- SA3200D for uptime – hardware redundancy across controllers, power and cooling, with automatic minute-level failover and a correctly engineered heartbeat and quorum design.
- Hyper Backup for recoverability – an independent copy on separate hardware at a separate site, satisfying the 3-2-1 principle the HA cluster alone cannot.
- Air gap plus immutability for ransomware resilience – a target attackers can’t reach, holding snapshots they can’t delete even with admin access.
- Verified restores – the backup is tested, not assumed.
Backed by SirapCare – support that goes beyond the warranty
Hardware is only as good as the support behind it. Every Synology system we supply can be backed by SirapCare, our dedicated support programme built around four pillars:- Advanced replacement — a replacement unit is dispatched before the faulty one is returned, so you’re not waiting on logistics while your business waits on you.
- Warranty extensions — protect your investment well beyond the standard cover, with predictable costs and no surprises down the line.
- Preventive maintenance — scheduled health checks that catch ageing drives, capacity ceilings and configuration drift before they cause an outage.
- Configuration support — as your environment grows and changes, our engineers are on hand to reconfigure, expand and tune your storage.
The outcome
The client now runs on storage engineered to stay online through a hardware failure, with a separately engineered backup that stands up to ransomware and site-level disasters because it is both unreachable and unalterable for its retention window. Just as importantly, the team understands which layer does what — so the next decision they make about their data is an informed one. And they have a single local partner accountable for the whole stack. Talk to Malta’s Synology Platinum Partner →Related guides
- Compliance backup and retention.
- UPS and power protection: a backup or HA system is only safe while it stays powered.
- Securing networked infrastructure for NIS2 and DORA.
Featured Products in this article
Kurt Paris
With an MSc in Software Engineering, and over 15 years in IT Management, Kurt Paris leads technology strategy at Sirap. Zebra Technologies, Domino and Cisco-certified, he helps Maltese businesses build resilient storage & backup infrastructure, Machine Vision & AutoID Automation
