An untested backup is a guess. This is the system that continuously proves ours can come back, from outside our own network, and says so out loud the moment it cannot.
The dangerous backup failures are the quiet ones. Your client reports success every night. The repository grows. The dashboard is green. And then the day you need to restore, you find out that months ago something broke and nothing told you:
Every one of these passes a "did the backup command succeed" check. The only thing that catches them is doing the restore and comparing bytes.
On a small VPS that lives on a different provider and a different network than our storage, a job runs every 15 minutes. It has no inside access. It talks to ServerCrate exactly the way one of your machines does, over the public REST endpoint, with nothing but a normal vault credential. Each cycle it:
restic backup to a real ServerCrate vault over the public endpoint.restic restore to pull it back to the VPS.The independence is the whole point. It is not checking a database flag or trusting our own internal metrics. It exercises the same path your restore would take, end to end, from outside our infrastructure, and it only passes if the bytes that come back are identical to the bytes that went in.
If any step fails, or the round trip takes longer than it should, it alerts immediately through Uptime Kuma, Telegram, and Discord, and the result is public on our live status page.
This is not hypothetical. The verifier exists because we needed it, and it has already earned its keep.
Shortly after launch, the verifier started failing on the backup step. Restores of anything past a trivial size would not complete. The cause was a single missing directive in our edge proxy: with no explicit body-size limit set, the proxy fell back to its default and silently rejected every restic pack over that limit with an HTTP 413. Small test backups looked perfect. Real backups died the moment they sent a real pack.
A "backup succeeded" check would never have found this. Restic surfaces it as a transfer error buried deep in the logs, not as an obvious failure. What found it was the canary restore coming back wrong, within 15 minutes, with an alert attached. We added the directive, the round trip went green, and the fix shipped before it could affect real data at scale.
We are telling you about a bug we shipped because that is the entire argument. Systems fail. The question is never whether a provider has had a problem. It is whether they hear about it from a verifier in 15 minutes or from a customer in the middle of a disaster.
We would rather be precise than impressive, so here is the honest boundary.
The verifier proves the full pipeline works: that a client on the open internet can write to a ServerCrate vault, that the data is stored intact, and that a restore returns it byte for byte. It proves our storage, our endpoint, our proxy, and our restic integration are healthy, continuously, against the real public path.
It does not reach into your individual repository and restore your data, because we cannot. Your backups are encrypted on your machine with a password we never receive. That is the point of zero-knowledge, and it also means we are unable to verify your specific repo on your behalf. The verifier proves the road is open and the destination is sound. Confirming that your own client is configured correctly and your own restores work is something we actively nudge you to do, with a restore-test step built into your dashboard onboarding, but it is yours to run.
None of this asks for your trust. That is the design.
A backup you have never restored is a hope. If you want managed restic storage where someone is restoring a canary every 15 minutes and saying so out loud when it breaks, that is what we built ServerCrate to be.
Encrypted, zero-knowledge, and continuously restore-tested. Free tier, no card required.
Cancel anytime. 10 GB free tier never expires. No egress fees.