Backups that ransomware cannot read, swap or quietly poison

Contents

1. 1Executive summary
2. 2The challenge
3. 3Architecture
4. 4How it works
5. 5Capabilities in detail
6. 6Security and data handling
7. 7Where it fits
8. 8Deployment and system requirements
9. 9Technical specifications
10. 10Getting started

1Executive summary

RecoveryVault treats the backup as the target it now is. Data is encrypted on the server before it leaves, every restore point is scored for ransomware as it is taken, and nothing is restored to another place without a second person. The result is a restore point you can trust on the worst day, not only a copy of the files.

2The challenge

Ransomware now goes after backups first: it deletes them, encrypts them or waits until the bad files are in every copy. Many organisations find out during the incident that their last good backup is weeks old, unreadable or reachable with the same stolen administrator password.

The TotalHeal approach. RecoveryVault encrypts on the server before anything leaves it, keeps incremental, deduplicated restore points on your storage or ours, scores every backup for ransomware, and restores only through approved, audited jobs.

3Architecture

4How it works

1. ProtectSwitch backup on for a server and attach a policy: what to back up, databases, schedule, window and retention.
2. Back upThe agent chunks changed data, encrypts it and uploads it straight to storage; the restore point is committed only when every object is confirmed.
3. ScoreEach run is scored 0–100 for ransomware; a suspect point opens an incident and the last good point is held.
4. VerifyVerification jobs read restore points back on a schedule, so you know they restore before you need them.
5. RestorePick a point and a target; restores to another server wait for a second person, and nothing on the target is deleted.

5Capabilities in detail

• Encrypted before it leavesAES-256-GCM on the server with keys derived from that server’s own root key. Storage and TotalHeal see only ciphertext, and every stored object is bound to its identity, so a swapped object is refused.
• Incremental and deduplicatedContent-defined chunking sends only what changed: one edit inside a 6 MiB file uploaded less than 3 MiB in our end-to-end test. Identical blocks are stored once.
• Databases, nativelyPostgreSQL and MySQL dumped by their own tools inside the backup run, with pre- and post-backup scripts for anything else that must be quiesced.
• Schedules, windows and retentionPer-policy schedules and backup windows, and grandfather-father-son retention: daily, weekly, monthly and yearly points kept as long as you set.
• Your storage or oursTotalHeal storage, or your own S3-compatible bucket (AWS S3, MinIO, Wasabi or a NAS with an S3 interface). Backup data goes straight from the server to storage.
• Ransomware score on every backupChange ratio, entropy jumps on normally compressible files, new extensions and deletions give a 0–100 score. At your threshold the point is marked suspect, an incident opens and the last good point is held.
• Restores that never destroy dataRestore to the same server, a folder or another server. Files are written through temporary copies, verified against their checksum, and replaced files are moved aside, never deleted.
• Four-eyes recoveryRestores to another server and rollbacks wait for a second person; the requester can never approve their own job. Every key release and job is in the tamper-evident audit.
• VerificationScheduled and on-demand verification jobs read restore points back and check them, so a backup is known to be restorable before it is needed.
• A lost server can be rebuiltEach server’s root key is escrowed sealed, and released only to the same server or to the agent running an approved restore job, sealed to that job’s one-time key.

6Security and data handling

• Only ciphertext leaves the serverStorage and TotalHeal never see backup content; objects are bound to their identity, so a swapped object is detected.
• Keys are released only to approved workA server’s key goes back to that server, or to the agent running an approved restore job, sealed to that job and audited.
• Restores never destroy dataReplaced files are moved aside, never deleted, and every restored file is checked against its checksum.
• A person, not a script, approvesCross-server restores and rollbacks need a second person; AI never approves.
• Never held hostageWithout a licence, a server that has data stays restore-only: you can always get your data back.

7Where it fits

8Deployment and system requirements

9Technical specifications

10Getting started

• The TotalHeal server agent on each Linux server, with backup switched on
• Storage: TotalHeal’s, or an S3-compatible bucket you own
• Outbound HTTPS from each server to the TotalHeal cloud and to the storage

Start a 30 days trial in the TotalHeal console with a Sttiz account. For a quote, an on-premises installation or the procurement dossier (compliance matrix, bill of materials, architecture and hardening, SLA, OEM authorisation letter), write to business@totalhealsecurity.com.