A new term is taking hold in medium and large enterprises – ResOps, short for Resilience Operations. We didn’t come up with it, but we wish we had – because it’s one of those concepts that just makes sense.
ResOps describes a shift that has been happening for a few years now. Resilience is moving from something you plan, to something that is an integral part of how an organisation runs – every day. In the same way that DevOps shifted software releases from big, periodic, high-stakes events into a flow of incremental pushes delivering continuous improvements, ResOps is set to be a game-changer for the way businesses approach Disaster Recovery (DR) and Business Continuity Planning (BCP).
The idea is sound, and it matters. But most of what has been written about ResOps so far stops at the strategy. It tells you resilience should be a continuous operating model, a board-level priority, a culture that breaks down silos between IT, security, and the business. All true. But, none of it tells you how you actually start to make the move to continuous resilience. How can you begin to test your ability to recover – every day, and actually prove it works.
That operational layer is where ResOps either works or quietly fails. It is also where Predatar has been building for years.
What ResOps actually means
Strip away the vendor framing and ResOps comes down to a simple proposition. Disruption is no longer an exceptional event to be planned for. It is a normal operating condition to be managed. Ransomware, outages, cloud complexity, and now AI agents acting on your data at machine speed mean that something will go wrong, and the question that matters is not whether you have a plan, but whether your critical services can keep running, or be restored cleanly, within a pre-defined timeframe the business can tolerate.
This reframes the central question of recovery. For two decades the metrics that mattered were RTO and RPO: how fast can we restore?, and how much data might we lose?. ResOps asks harder questions. When you restore, are you restoring something clean, trusted, and actually usable?, or are you reintroducing the very problem you were trying to recover from? A growing number of teams now track Mean Time to Clean Recovery (MTCR), not just recovery time – precisely because a fast restore of compromised data is not a recovery at all.
That is the real test of ResOps. Not the strategy deck. The clean restore, under pressure, proven in advance.
The gap between the idea and the operation
The reality is that most organisations already believe they can recover. Backups are running. Immutability is in place. The plan is documented. And yet recoveries still fail – often – and expensively, when they are needed most.
There are three reasons, and ResOps as currently described by most vendors does not fully address any of them.
First, recoverability is assumed rather than proven. Backups complete successfully and everyone moves on. But a successful backup is not a successful recovery. The only way to know a system will come back is to actually bring it back and test it, continuously, not once a year in a tabletop exercise or DR test.
Second, malware is already inside the backups. Immutability protects a copy from being changed; it does nothing to verify that copy was clean when it was written. In practice, dormant ransomware and other threats sit in backup data waiting to be restored. Predatar has found previously undetected malware in the backups of more than 90% of its customers, organisations that in most cases had strong, best-in-class security tools in place. Anomaly detection alone does not catch this. You have to recover the workload, scan it properly, and verify it.
Third, real infrastructure is fragmented. Most enterprises run several backup and storage platforms, and the resilience tooling offered by each vendor only validates that vendor’s own data. Veeam’s testing covers Veeam workloads. Cohesity covers Cohesity, Rubrik’s covers Rubrik, Etc. A ResOps model that only works on one vendor’s stack is not operational resilience. It is a partial view that leaves blind spots that can be exploited.
How Predatar operationalises ResOps
Predatar exists to close the gap between believing you can recover and proving it. The approach rests on three things the broader ResOps conversation talks around but rarely operationalises.
Continuous, pre-emptive recovery testing. Instead of waiting for an incident, Predatar automatically and repeatedly restores backups and primary snapshots into an isolated environment and tests whether those systems come back clean and usable. This runs at scale, without manual effort, so that when a crisis hits you already know what recovers and what does not. Continuous validation stops being a phrase in a strategy document and becomes a daily, measurable operation.
Clean recovery, not just detection. Where most tools stop at flagging an anomaly, Predatar goes further. It restores the suspect workload, runs a full malware scan to confirm whether an infection is real, and where necessary cleans the workload before it is ever returned to production. This is the difference between knowing something might be wrong and being able to recover something you know is right. It is the operational meaning of the ‘clean’ in clean recovery.
Vendor-agnostic by design. Predatar’s CleanRoom works across Veeam, Rubrik, Cohesity, IBM Storage Protect, IBM Defender DataProtect, IBM FlashSystem, Pure Storage, and Zerto validating both backups and primary snapshots from one central place under a single subscription. Fragmented storage does not have to mean fragmented resilience. For a ResOps model to be real, it has to span the estate you actually run, not the one a single vendor wishes you ran.
Resilience operations you can start on Monday
There is a perception that resilience operations are an enterprise-scale, capital-heavy undertaking, the kind of thing tied to large hardware estates and big upfront investment. That perception is the single biggest barrier to adoption, and it is no longer true.
Predatar’s CleanRoom is delivered as a virtual appliance that deploys into infrastructure you already have. More than 70% of customers stand it up using existing resources, with no new hardware. The most successful teams do not try to operationalise everything at once. They start with a minimum viable business service, a critical application or a key set of workloads, prove recovery there, and expand. That is what makes ResOps an operation rather than a project: it is something you begin now and run continuously, not a transformation you wait a year to fund.
The point of ResOps
The industry is right that resilience needs to become an operation. Where the current conversation falls short is in treating it as primarily a matter of strategy, culture, and organisational alignment. Those things matter, but they do not restore a single system. Resilience is not proven in a framework. It is proven in a clean, complete, timely restore, on the worst day, across whatever mix of platforms you actually run.
That is the part Predatar has spent years building, and it is the part that turns ResOps from a good idea into something you can rely on.
Learn more about ResOps here:
What is ResOps? & ResOps FAQS
Take the first steps towards making ResOps a reailty.
Predatar delivers continuous, automated recovery assurance across multi-vendor storage and backup environments. Book a demo or contact our friendly team of experts.
