Restore verification
Once a week a randomly chosen copy is restored in an isolated environment. We compare file checksums and database schema integrity. A mismatch is an incident, not a line in a log.
We back up your servers and databases, then routinely restore those copies and compare them against the source. Without that step, a backup is an assumption — not a guarantee.
Once a week a randomly chosen copy is restored in an isolated environment. We compare file checksums and database schema integrity. A mismatch is an incident, not a line in a log.
A copy is written in Moscow and mirrored in Amsterdam. You can keep a single region if your data-handling policy requires it.
The key is generated on your side and never reaches us. We hold encrypted blocks and schedule metadata — we cannot decrypt the contents without your key.
One email a week: what was copied, what was verified, where the mismatches are. No daily "all good" emails — nobody reads those anyway.
The agent runs on Linux and FreeBSD, copies file systems and logical volumes, and for databases uses their own consistent-dump mechanisms — no "live" copies that ignore transactions.
The list of what we don't do is shorter and more honest: we don't back up Windows, we don't attach to third-party S3-compatible storage as a source, and we don't promise an RPO under fifteen minutes.
Usually one evening. You install the agent, point it at what to copy, and pick a maintenance window. The first full copy takes anywhere from a few hours to a day depending on volume and bandwidth; the rest are incremental.
| Component | State | Region |
|---|---|---|
| Copy intake | operational | Moscow, Amsterdam |
| Restore verification | operational | Amsterdam |
| Control panel | operational | Moscow |
| CSV report export | delayed | Moscow |
Details and incident history are on the status page.