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

Why most backup architectures fail under modern ransomware

The economic case for ransomware turned on the realization 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 optimized 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.

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.

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.