Separate Your Data From Your Systems: Immutable by Design

Most organisations protect their servers as though the servers were the valuable thing. They image them, back them up, patch them anxiously, and when one dies or gets compromised, they pour hours into restoring it exactly as it was. Then their data, which actually is the valuable part, lives on those same servers with whatever protection the server happens to have received.

Flip that relationship and a great deal of security becomes simpler. Treat systems as disposable and data as precious. Build servers from code so they can be replaced in minutes rather than restored in days. Then concentrate real protection effort where it belongs: on the data itself, tracked through its entire life, backed up deliberately, and increasingly stored somewhere that isn’t the system processing it at all.

Systems you redeploy, not repair #

The old model treated servers like pets. Each one had a name, a personality, and a history of manual fixes that nobody fully documented. When a pet-server died, recovery meant archaeology: reconstructing years of accumulated changes from memory, notes and hope.

The modern model treats servers like cattle, to borrow the DevOps phrase that has outlived plenty of trendier ones. You do not nurse a terminally ill cow back to health; you replace it and move on. In practice this means:

Infrastructure as code. Every server, container and configuration is defined declaratively: Terraform for the platform, Ansible or cloud-init for the host, container images for the workloads. A running instance is just one materialisation of that definition, indistinguishable from any other.

Immutable deployment. Instead of logging in to servers to change or patch them, you build a new version, test it, and roll it out, replacing the old instances wholesale. Nothing accumulates. Configuration drift, the quiet accumulation of manual changes that makes every environment unique and unexplainable, becomes impossible by construction.

Redeployment replaces restoration. Here is the payoff that surprises people: a properly built cattle-fleet barely needs backing up at all. If a server is compromised, corrupted or simply lost, you do not restore it. You redeploy it from code in minutes, because the definition is the backup. The recovery conversation stops being “how do we get this machine back?” and becomes “how quickly can we launch replacements?”, which is a much better conversation to have during an incident.

This also shrinks the ransomware surface dramatically. Encryption only harms you if the encrypted thing is hard to reproduce. Disposable machines built from Git repositories are cheap to reproduce.

All the attention turns to the data #

Once systems are disposable, everything irreplaceable lives in the data. That deserves its own discipline, and it starts with a question most organisations have never answered precisely: what data do we hold, where does it live, who touches it, and what happens to it over time?

Track data through its lifecycle. Created, processed, copied, archived, destroyed: each stage should be known and deliberate. Lifecycle tracking pays off repeatedly. It tells you where your regulatory obligations attach, since PDPA and similar regimes follow the data rather than the machine. It exposes the forgotten copies nobody accounts for, which are where breaches actually happen. And it tells you what can be deleted today, which is often the cheapest risk reduction available: data that no longer exists cannot leak.

Back up the data deliberately, not the machines accidentally. With systems defined as code, backups become focused and honest: database dumps, object storage replication, configuration repositories, secrets vaults. Small, verifiable sets of genuinely important things rather than nightly images of everything including the cruft.

Consider keeping data off the processing systems entirely. Applications can hold almost nothing locally: state in managed databases, files in object storage, secrets in a vault. The processing tier then contains nothing worth stealing, which means a compromised application server is an operational nuisance instead of a reportable event. As a bonus, data services designed for storage typically offer stronger built-in protections, versioning, immutability options, fine-grained access control, than any general-purpose server will ever receive.

Run one fleet, not three #

There is a second simplification hiding inside this one, and it concerns the fleet itself. Look at the cost structure of any organisation running a mixed Windows-and-Linux estate and count the duplication:

• Two skill sets. Windows administration and Linux administration are different professions. Supporting both means either hiring specialists in each or accepting shallow coverage of both. Roughly speaking, twice the team for the same number of machines.
• Two toolchains. Patching, monitoring, configuration management, hardening baselines, agent deployments: each exists in duplicate, each licensed, maintained and upgraded separately. Twice the budget, twice the attack surface in management infrastructure, twice the things that can quietly fall behind.
• Two sets of failure modes. Incident response playbooks, forensic capability and disaster recovery procedures all fork per platform. During an incident, that fork costs exactly the time you do not have.

The airline analogy earns its keep here. No successful carrier flies every aircraft type: each additional type multiplies maintenance programmes, spare parts inventories, crew certifications, training pipelines and hangar tooling, and those costs recur forever, long after the purchase decision faded from memory. Airlines therefore standardise ruthlessly on the smallest set of types that serves their routes. IT estates deserve the same arithmetic. Choosing your standard operating system, and holding the line on it, converts two of everything into one, and the savings compound every year.

Standardisation also strengthens security directly. One fleet means one hardening baseline, deeply understood; one patching pipeline, tuned and trusted; one set of detection rules that fit the actual estate. Depth beats coverage every time.

Where to start #

1. Pick a workload and make it disposable. Rebuild it from code until a full replacement takes minutes and nothing about it is hand-configured.
2. Inventory your data honestly. Where it lives, on what systems, under whose control, and what could be deleted tomorrow.
3. Move state off application servers into purpose-built storage with proper access control and immutability options.
4. Cost your fleet split honestly. Tally the duplicated licences, tools and headcount against the price of consolidating. Present it to leadership the way an airline evaluates a route: recurring cost against recurring revenue.
5. Set the standard going forward: new systems join the standard fleet, defined as code, stateless wherever possible. Exceptions require a reason written down.

Separation of concerns is one of engineering’s oldest lessons, and security benefits from applying it literally: systems are ephemeral, data is permanent, and protecting each according to its true nature costs less than protecting both badly.

Our Configuration & Architecture Assessment maps where your data lives versus where it is processed and designs the separation path, and our Linux hardening practice builds the single-fleet baseline that makes standardisation pay. Or schedule an Engineering & Scoping Session to plan it with your team.