Backups attackers can't encrypt, exfiltrate, or destroy.

Why most backup architectures fail under modern ransomware

The economic case for ransomware turned on the realisation that the attacker doesn't need to read your data — they need to deny you access to it. The standard answer was "back it up." That worked until ransomware operators started encrypting the backup targets too, and started exfiltrating before encrypting to add a double-extortion layer.

How SkyeConnex changes the calculus

1. No single backup target

SkyeDATA targets the multi-cloud RAID substrate. Backups are Reed-Solomon-encoded across seven providers. An attacker who compromises one — or two — backup providers leaves the data fully recoverable. There is no single backup destination to encrypt.

2. No plaintext to exfiltrate

Even if an attacker pulled shards from all seven providers, they would hold ciphertext for which the keys are wrapped by a User Master Key the server never holds. Double-extortion ("we'll publish your data") fails when the data is unreadable.

3. Versioned with signed provenance

Every file carries a hash-chain provenance from upload through every read — tamper-evident. Per-file Integrity Certificates, dual-signed with HMAC-SHA-256 and ML-DSA-87, let you prove which version was the last clean one before compromise. Restore decisions are auditable.

4. Geo-fenced storage

Ransomware operators frequently route exfil through jurisdictions optimised for non-cooperation. Geo-fencing means you choose where the backup shards live. Combined with the topology, exfil-from-compromise becomes operationally hard.

What SkyeDATA actually does

SkyeDATA is the encrypted backup pipeline that targets SkyeConnex multi-cloud RAID as its destination. Scheduled or one-shot. Chunk-level SHA-256 validated. The same encrypt-then-scatter pipeline as live storage.

Common deployment patterns: database backups, file-server backups, server-image archives, and the retargeting of existing backup tools (Veeam, AWS Backup, Bacula) at SkyeBucket — the S3-compatible drop-in.

What recovery looks like

Recovery is just the read path in reverse: fetch the shard manifest, parallel-pull from any five of seven providers, RS-decode, AES-GCM-decrypt on the client. No provider needs to be uncompromised. No backup target needs to be uncompromised. The recovery succeeds as long as any five shards remain readable.

Why backups became the new attack surface

Through 2024-2026, sophisticated ransomware crews — Black Basta, BlackCat / ALPHV, LockBit's successors — adapted to the standard playbook of offline backups. They now attack backup infrastructure first, encrypt or delete the backup capability, then move to production. By the time the operator notices the production incident, the backup target is already unusable.

The "immutable storage" workaround and its limits

Object-lock features (AWS S3 Object Lock, Azure Immutable Blob, B2 Object Lock) prevent overwrites for a configured retention period. They help — but the immutability is enforced by the same provider whose plane is in the attacker's potential blast-radius. If the attacker compromises the provider's control plane (rare but consequential), even immutable storage is reachable.

The architectural answer

Multi-cloud RAID inverts the assumption that one storage target is the trust anchor. With seven distinct providers in customer-chosen jurisdictions, an attacker compromising one — or two — backup provider accounts cannot encrypt or delete the backup. Five providers must be simultaneously compromised for the backup to be irrecoverable. The required attack-surface coordination collapses the economics of ransomware.

Recovery operationally

Recovery is the read path in reverse. Fetch the shard manifest. Parallel-pull shards from any five of seven providers (up to two can be unreachable or compromised). Reed-Solomon decode on the recovery host. AES-GCM decrypt frame-by-frame using the customer's wrap key. Stream plaintext into restoration. No provider needs to be uncompromised. The recovery succeeds as long as any five shards remain readable.

Provable clean restore points

Per-file integrity certificates dual-signed with HMAC-SHA-256 and ML-DSA-87 let you cryptographically prove which backup version was the last clean one before compromise. Restore decisions become auditable artefacts. "Did this version exist before the attack?" answers itself with a signed JSON receipt verifiable offline.

Retargeting existing backup tools

SkyeBucket — the S3-compatible drop-in gateway at s3.skyeconnex.com — works with Veeam, AWS Backup, Bacula, and other backup tools that target S3. The retargeting is one endpoint change. No new agents, no new infrastructure, no new operational pattern. The architectural sovereignty is inherited.

Double-extortion calculus

Modern ransomware crews exfiltrate before encrypting, then threaten publication unless the ransom is paid. Even if an attacker pulled shards from all seven providers (which requires compromising seven accounts in seven jurisdictions), they would hold ciphertext for which the wrap key was derived only on the original customer's device. The economics of exfiltration collapse — there is no readable data to publish.