A Compliance-Grade Backup Appliance on Synology RS822RP+

“We have backups” and “we can prove we restored a specific file to how it looked on a specific date” are very different claims. Compliance cares about the second one.

A Malta-based professional services office needed to bring its backups up to the standard its clients and regulators now expect. The bar has moved. It is no longer enough to have a copy of the data somewhere. A firm increasingly has to demonstrate that records are retained for a defined period, that they can be recovered to a point in time, and that the backup itself can’t be quietly tampered with or destroyed, including by ransomware or a disgruntled insider. As Malta’s only Synology Platinum Partner and a long-standing Eaton power partner, Sirap specified a compact, redundant backup appliance and, around it, the policies that turn storage into evidence.

The challenge

The office was relying on ad-hoc copies to a single external drive: no versioning, no redundancy, and no protection if the power dropped mid-copy. For a firm handling client records that left two gaps that mattered. It couldn’t prove a clean, point-in-time copy existed for any given date, and a single drive or power-supply failure could take the only backup with it. They needed retention they could stand behind in an audit, and hardware that wouldn’t itself become the weak link.

What “compliance” actually demands of a backup

Compliance is often treated as a vague pressure, so it helps to be concrete about what it asks of a backup, because each requirement maps to a specific technical control. Under the GDPR, an organisation has to be able to restore the availability of personal data in a timely manner after an incident, and to keep it only as long as it has a lawful reason to. The EU’s NIS2 directive, now being transposed across member states including Malta, pushes the same expectations harder for a growing set of organisations: demonstrable resilience, tested recovery, and accountability for it. None of that is satisfied by “there’s a copy on a drive in the cupboard.” It calls for defined retention, protection against tampering, verified restores, and a record that the controls are actually running. We designed the deployment backwards from those requirements rather than forwards from the hardware.

The hardware: why redundant power was the starting point

We deployed a Synology RS822RP+, a 4-bay 1U rackmount NAS built around an AMD Ryzen V1500B quad-core processor with ECC memory. The defining choice for a backup role is the RP, the redundant power supply. A backup appliance that dies mid-window because a single PSU failed is worse than useless: it fails precisely when you’re depending on it. Dual hot-swappable supplies remove the most common single point of failure on a rackmount unit, so a failed PSU is a service call, not a missed backup. The ECC memory matters for the same reason: it guards against the bit-level errors that can silently poison a backup set as it’s written. We chose the rackmount form factor deliberately too; even in a small office, a unit fixed in a rack with proper power and cooling is far less likely to be unplugged, knocked, or “tidied away” than a desktop box under someone’s desk.

Versioning isn’t the same as immutability

The instinct is to reach for snapshots and call it done. Snapshots are the right foundation. On Btrfs they’re near-instant and low-overhead, and they let the office restore a file, folder or share to exactly how it looked on a chosen day. But for compliance and ransomware resilience, ordinary snapshots have a hole: anyone with administrator access can delete them, and that’s exactly what modern ransomware does before it encrypts.

Immutable (WriteOnce) snapshots: the control auditors actually want

On DSM 7.2 with Btrfs, snapshots can be made immutable using WriteOnce (WORM) technology, locked for a defined retention period during which no one, not even an administrator or a compromised admin account, can alter or delete them. This is the difference between a backup you hope survives an incident and one that is guaranteed to. It’s worth separating from simple snapshot “locking,” which only stops the automatic retention policy from pruning a snapshot early; immutability is the stronger control, designed to withstand a malicious actor with full access. For a firm that has to evidence a tamper-proof retention chain, that distinction is the whole point.

Designing the retention policy, not just enabling it

Retention is where good intentions usually fall apart, because the defaults rarely match any real obligation. We mapped the schedule to the firm’s actual requirements: how frequently recovery points are captured, how long each tier is kept, and when older versions roll off. A typical structure keeps frequent short-term points for everyday “I deleted the wrong thing” recovery, plus longer-spaced points held for the months or years the firm is required to retain them. The aim is a retention chain that is both provable and defensible: long enough to meet the obligation, deliberate enough that you can explain in an audit why each point exists and when it expires. Storage is finite, so designing this properly is also what keeps the appliance from silently filling up.

A backup you haven’t restored is a guess

The most common and most dangerous failure in backup is the one nobody notices until it’s too late: the job ran green for two years and then didn’t actually restore. Compliance regimes increasingly expect tested recovery for exactly this reason. We validated restores as part of handover, confirming that real files come back intact and usable, not just that the backup reports success. We also set up DSM’s notifications so the office is told when a job fails or a drive reports trouble, rather than discovering it during an incident. Synology’s logging gives the firm the audit trail to show backups ran and restores were tested, which is itself part of what an auditor wants to see.