Covert Copy Just Got Smarter: Introducing Incremental Backup Support

There's a well-documented playbook that ransomware operators follow. They get in, stay quiet, and spend days, weeks, or months mapping the environment. They seek valuable data along with backup infrastructure and data they can find, disable, and encrypt. By the time the ransom note appears, the recovery options are already gone.

Insider threat actors or stolen admin credentials are an even tougher threat to defend against. They can simply login and steal your data without triggering any kind of alarm.

The most effective defense turns out to be the simplest: make the backup invisible. A recovery copy that doesn't appear in directory listings, doesn't respond to API calls, and doesn't exist anywhere an attacker scanning the environment would think to look. If the backup can't be found, it can't be neutralized. And even if someone with valid credentials can find it, they can’t access the data without approvals from multiple individuals.

That's the premise behind Wasabi Covert Copy™ technology: air-gapped from primary storage that’s unlisted from standard S3 operations and protected by root credentials, Multi-Factor Authentication (MFA), and Multi-User Authorization (MUA) that requires multiple people to unlock. The threat finds nothing, executes anyway, and the organization recovers from a clean copy the attacker never knew existed.

But there's a version of this story with a damaging outcome, where the recovery copy is intact, invisible, and inaccessible to attackers, but also months out of date. Where the security worked perfectly, but the restore only brought operations back to a state that was months behind where they needed to be.

That gap is what the latest enhancement to Covert Copy is built to close.

Why wasn’t invisibility enough?

Our initial Covert Copy release created a protected copy at a point in time. That copy was genuinely secure, with the air gap and access controls enforced at the infrastructure level. But it was static. If the source bucket evolved after the Covert Copy was created, the protected copy didn't follow. The only way to bring it to current state was to delete it and create a new Covert Copy bucket from the updated source bucket.

For organizations with largely static datasets, that was a workable constraint. For anyone running live workloads (application data that changes weekly, configuration files that get updated with every deployment, object stores that grow continuously), Covert Copy was not the best fit. In those cases, customers would rely on Wasabi Object Lock for immutability but would not get Covert Copy’s benefits of logical air-gapping and invisibility.

Updating a Covert Copy was a manual process. It required proper authorization and coordination across multiple people to delete the old bucket and create a new one from the updated source. It was still a valuable protection but was limited to use cases where the data did not change frequently.

The manual nature of keeping a Covert Copy updated could lead some organizations to let their Covert Copy get too out of sync with the source bucket. The security model stayed intact with the copy remaining invisible and inaccessible, but without manual intervention, the data inside it drifted further from the source. A recovery point that's three months stale can still be a lifeline. One that's twelve months stale is a different conversation entirely.

That's the operational gap that Covert Copy has now closed.

What does the latest version Covert Copy do?

When a Covert Copy cycle runs, the system identifies newly created object versions in the source bucket that are not yet present in the Covert Copy and replicates them over. Everything already present in the Covert Copy remains untouched. It's a targeted delta replication, not a rebuild, and it runs entirely within Wasabi's internal infrastructure.

Throughout that process, the Covert Copy bucket stays fully air-gapped, unlisted from S3 operations, and subject to the same access controls that govern every other interaction with it: root credentials, MFA, and MUA.  This new capability gives Covert Copy the ability to support incremental backups.

There is no exposure window. The bucket is as invisible during a refresh as it is at rest.

Administrators configure refresh intervals at 30, 60, or 90 days, balancing operational requirements against recovery objectives. The right interval depends on how frequently source data changes and what the recovery requirements demand.

What does this mean for cyber resilience?

The dominant model for backup security has been defense-in-depth: redundant copies across multiple systems that an attacker would have to find and neutralize before executing. The problem is that depth still assumes discoverability. More backup systems mean more targets.

Covert Copy operates on a different premise entirely. The security comes not from redundancy but from the impossibility of targeting something you can't locate. That holds even when other backup infrastructure is compromised.

For IT and security teams, the new Covert Copy shifts from a periodic manual effort into a continuously maintained recovery asset. For organizations in regulated industries, that continuity carries direct compliance value. A data protection architecture that can demonstrate timestamped alignment between production data and a protected recovery copy is a more defensible position than one documented by a rebuild log from months prior.

Resilience isn't just surviving an attack. It's restoring operations with enough fidelity that the business can actually resume. That requires a recovery point that's current. Covert Copy makes that possible without changing anything about how Covert Copy data is secured.

What does this mean in practice?

For IT teams, this shift is more significant than it might appear on paper. Maintaining a Covert Copy under the old model meant carrying a recurring operational debt: track when the last rebuild happened, assess whether the gap had grown too wide, coordinate the authorization required to tear it down, and reconstruct it from the updated source. In environments where that process competed with everything else in the queue, it could get deprioritized. The copy stayed hidden and secure, but the window between it and the current source data widened.

With the latest release of Covert Copy, the rebuild cycle is replaced by a scheduled, automated process that runs without administrative intervention between cycles. IT teams don't have to track drift or schedule maintenance windows around it. The protection posture stays current, and the effort required to maintain it drops to configuring an interval once and verifying it on a schedule.

The result is a recovery architecture that's easier to maintain and more reliable when it matters. Not because the security got simpler, but because the operational burden of keeping it current did.