Cloud backup and recovery
The backup is not the product. The restore is.
Backup is the easy half
Copying data to a remote location is a solved problem. What separates a backup service from a storage bill is everything that happens afterwards: whether the copy is still intact, whether an attacker could have altered it, whether you can find the version from before the incident, and how long it takes to get it back where it belongs.
So the design here starts at the restore and works backwards. Data is encrypted on your machine and stored in chunks, which is what makes a partial restore cheap — the client fetches the chunks for the files you asked for and nothing else. Versions are kept for the full retention period and cannot be removed early, which is what makes a restore possible at all after a bad day.
Four ways data comes back
A single file or folder
Pick the path and the version, restore it. Seconds to minutes — nothing else has to be downloaded.
A complete system
Reinstall the client on the new machine, authenticate with a read token, restore the full tree. The step-by-step walkthrough is in the blog.
An earlier point in time
Every run keeps its own version. Go back to the state before the bad edit, the failed migration or the encryption event.
After a ransomware attack
Retained versions are immutable, so the attacker's credentials cannot reach them. You restore from a point before the intrusion.
What actually sets your recovery time
Recovery time is dominated by two things, and neither is marketing: how much you pull back, and how fast your line is. A 50 GB dataset over a 200 Mbit/s connection is roughly half an hour of transfer; a terabyte over the same line is a day. Planning a recovery means knowing which subset has to come back first — that subset is usually small.
The parts we control are built for that: transfers are chunked and resume where they broke off instead of restarting, restores are selective rather than all-or-nothing, and read access uses its own token so a restore never needs write credentials. Bandwidth is not throttled and restores are not billed as an extra.
Test the restore, not the backup
A green backup job proves that data went out. It proves nothing about coming back. Restore a handful of real files to a scratch location once a quarter, and restore a full system to spare hardware or a VM once a year. The exercise takes an afternoon and it is the only way to find out — before it counts — whether your retention period is long enough, whether the right directories are actually covered, and who knows where the keys are.
Start free · Cloud backup services · Security architecture
Frequently asked questions
What is the difference between backup and recovery?
Backup is the copy; recovery is getting the data back into production. Most backup products are judged on the first and fail on the second — an archive that restores slowly, partially or not at all was never really a backup.
How long does a restore take?
Mostly your download bandwidth times the amount you are pulling back. A single file or folder is a matter of seconds to minutes because the client fetches only the chunks it needs. A full restore of a large dataset runs at line speed and resumes after an interruption instead of starting over.
Can I restore an older version of a file?
Yes. Every run keeps its own version for the length of the retention period you set, so you can go back to the state before a bad edit, a failed migration or an encryption event — not just to last night.
How does this help against ransomware?
Two properties do the work. Backups are immutable while retention runs, so stolen credentials cannot delete or encrypt them, and versioning means there is always a point in time before the attack to return to.