TotalHealRecoveryVault

How 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.

Reference architecture

Key capabilities

• 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.

Deployment options

System requirements

Technical specifications