It has to survive the machine it came from.
A backup product is a product that holds a copy of everything. Here is exactly what that copy is protected by, and what it is separated from — starting with the one claim the rest of the product is built around.
The machine cannot erase what it has already stored.
Encryption stops a backup being read. It does nothing about a backup being deleted — and ransomware looks for the backup target first. The credential we issue to an agent writes into that device’s own folder and nowhere else, and it reads within your workspace’s bucket, which is what makes a restore onto a different machine possible. What it cannot do is erase: not a pack file, not an index, not the repository’s own metadata. Every one of those is denied to it, and the policy on each device key is re-checked hourly. Retention — and the collection that actually frees the space — runs from the server, with a credential the endpoint never sees.
Said precisely, because the distinction matters to anyone who has read a storage spec: this is credential scoping, not object-lock or WORM storage. We do not use S3 Object Lock and we do not claim to. What we claim is narrower and checkable — the key that lives on your machine has no delete permission on backup data. One narrow delete grant does exist on that key, on the backup engine’s own session markers, and it reaches nothing you could restore from.
Encrypted before it leaves, and separated after it lands.
Six mechanisms, each of them something you can ask us to demonstrate rather than something you have to take on faith.
Encrypted before it leaves
Data is deduplicated, compressed and encrypted on the machine, then uploaded. The agent’s own configuration — tokens, repository credentials — is held AES-256 encrypted at rest, with the key protected by the operating system’s own keystore on Windows.
One vault per device
Each device gets its own repository, its own encryption key and its own scoped storage credentials inside your workspace’s bucket. One endpoint’s key cannot make sense of another endpoint’s history, because it does not hold that repository’s key.
Tenant isolation by construction
Every workspace is a separate bucket and a separate set of devices, and the workspace on a request is taken from the verified session token — never from a header, a body field or a URL. The identity is not something the request gets to state.
The agent opens no inbound port
Commands reach the agent over an outbound, per-device stream with its own scoped credentials; results come back over ordinary HTTPS. Nothing on the machine accepts a connection from the network, so there is no firewall hole to open.
A silent device is a visible device
Every agent checks in roughly once a minute, and a device that goes quiet is emailed to the workspace’s owners and admins rather than left in a queue. Eighteen kinds of alert, in the console and in your inbox.
Workspaces, roles and expiring invites
Separate workspaces per client or per site, owner / admin / member roles governing who can administer a workspace and who can remove things from it, and invite links that expire rather than sitting in an inbox forever.
“It ran” and “it got everything” are two answers.
When a run finishes, every snapshot it wrote is checked against the repository — the tree is walked and every object it references is confirmed present. If that check cannot finish, the run is recorded as unverified rather than quietly as a success.
Agents update themselves, safely
A new build is downloaded, checked against its SHA-256 and swapped in by the agent itself — with the old binary kept and rolled back automatically if the new one fails to start. The outcome is recorded per device.
Expiry happens on the server
Old points age out under a retention policy executed server-side. The endpoint has no part in that decision and no credential to carry it out. Nothing on your machine decides when its own history ends.
Every run is a new point
Nothing overwrites. A run adds a restore point beside the ones before it, so there is always a version from before the encryption event — not a mirror of it.
Two things on the roadmap, and no date on either.
Both are asked for in procurement, both are planned, and neither exists today. We would rather list them here as roadmap than let them be read as features.
Bring your own storage Roadmap
Point a workspace at your own S3-compatible bucket or an on-premise object store and keep the console. Priced as a seat rather than by capacity.
Reports you can hand to an auditor Roadmap
Scheduled PDF and CSV summaries — protection coverage, success rate, failures and retention proof — emailed on the first of the month.
We are not giving either a ship date, because the ones we would give you would be wrong.
On the endpoint
- Encrypted before upload, with a per-device key
- Agent configuration AES-256 encrypted at rest
- Wrapping key in the Windows keystore
- No inbound port, no listening service
- Outbound command stream with scoped credentials
- Self-update verified against SHA-256, with rollback
In storage
- One repository per device, one bucket per workspace
- A device credential that can write and read, never delete
- Device key policy re-checked hourly
- Retention and space reclamation run server-side only
- Versioned restore points — nothing overwrites
- Snapshots verified after they are written
Around the workspace
- Workspace taken from the verified session token
- Never from a header, a body field or a URL
- Owner / admin / member roles
- Invite links that expire
- Per-client or per-site workspace separation
- Alerting to owners and admins by email
What we do not claim
- Not S3 Object Lock
- Not WORM or immutable storage
- Not zero-knowledge — key management is on our side
- Not bare-metal recovery or disk imaging
- Not macOS or Linux
- Not a catch-up of missed schedule slots
What we do claim
- The endpoint key has no delete permission on backup data
- A restore works while the source machine is dead
- A run that cannot be verified is marked unverified
- A skipped file is named against the job
- A silent agent raises an alert
- No egress charge on any plan, including the trial
Roadmap, not shipped
- Bring your own S3-compatible or on-premise bucket
- Scheduled PDF and CSV auditor reports
- Neither carries a ship date
The ones a procurement review asks.
Is this immutable or object-lock storage?
No, and we will not call it that. There is no S3 Object Lock and no WORM tier underneath. The mechanism is credential scoping: the storage credential issued to your machine can write new data and read that device’s own history, and has no delete permission on backup data at all — not a pack file, not an index, not the repository’s own metadata. Retention expiry runs on the server with a credential the endpoint never sees. It is a narrower claim than “immutable”, and it is one you can verify.
So does it actually stop ransomware?
It does not stop the encryption on your machine — nothing that runs on the endpoint can promise that. What it does is make the history unreachable from the compromised machine. Every run is a separate restore point, nothing overwrites, and the key on that endpoint cannot remove any of them. So there is a version from before, and you can read it back from the console.
Is it zero-knowledge? Can you read my files?
It is not a zero-knowledge product, and we would rather you knew that now than during a procurement review. Data is encrypted on the machine with a key unique to that device, and the agent configuration is held AES-256 encrypted with the wrapping key in the Windows keystore. But key management sits on our side, which is what makes a browser restore of one file possible while the source machine is dead. If you need the keys never to leave your side, we are not the right product yet.
How are our workspaces kept apart from another customer’s?
Every workspace is a separate bucket and a separate set of devices. The workspace on a request is taken from the verified session token, never from a header, a body field or a URL — the identity is not something the request gets to state.
Does the agent open a port on our network?
No. Commands reach the agent over an outbound, per-device stream with its own scoped credentials, and results come back over ordinary HTTPS. Nothing on the machine accepts a connection from the network, so there is no firewall hole to open and nothing for an attacker to reach from outside it.
How do we prove to an auditor that backups are running?
Today, from the console: the fleet health score, recovery readiness, the failed-snapshot queue and the activity log, which exports. Scheduled PDF and CSV summaries covering coverage, success rate, failures and retention proof are on the roadmap and are not shipped.
Where is the data stored?
In S3-compatible object storage — a dedicated bucket per workspace, and one repository per device inside it. Pointing a workspace at your own bucket or an on-premise store is on the roadmap, not shipped.
Every device name and figure on this page is demo data.
Start with Comsky Backup.
Grow into the ecosystem.
One account opens every Comsky product — and one invoice covers them, however many you run.